День двести семьдесят седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
6. Перед началом рефакторинга
В какой-то момент каждому программисту приходится делать рефакторинг уже существующего кода. Но, прежде чем сделать это, подумайте о следующем, так как это может сэкономить вам и другим много времени (и боли):
1. Наилучший подход к реструктуризации начинается с оценки существующей кодовой базы и тестов, написанных для этого кода. Это поможет вам понять сильные и слабые стороны кода в его нынешнем виде, чтобы вы могли сохранить сильные стороны и избежать ошибок. Мы все думаем, что можем сделать лучше, чем то, что уже существует… пока не получаем нечто такое же или даже хуже того, что было, потому что мы не смогли извлечь уроки из ошибок существующей системы.

2. Избегайте соблазна переписать всё. Лучше всего использовать как можно больше существующего кода. Независимо от того, насколько он уродлив, он уже был протестирован, проверен и т. д. Выбрасывая старый код, особенно если он был в продакшене, вы выбрасываете месяцы (или годы) проверенного, закаленного в боях кода, который, возможно, имел определённые обходные пути и обрабатывал ошибки, о которых вы не знаете. Если вы не принимаете это во внимание, новый код, который вы пишете, может в конечном итоге выдавать те же загадочные ошибки, которые были исправлены в старом коде. Это впустую потратит время, усилия и знания, полученные за эти годы.

3. Несколько последовательных изменений лучше, чем одно большое. Инкрементные изменения позволяют легче оценить влияние на систему с помощью обратной связи, например, от тестов. Неприятно видеть сотню неудачных тестов после внесения изменений. Это разочаровывает и раздражает, что, в свою очередь, может привести к неправильным решениям. Пару неудачных тестов за раз легче исправить, что приводит к более управляемому подходу.

4. После каждой итерации разработки важно убедиться, что существующие тесты успешно проходят. Добавьте новые тесты, если существующих тестов недостаточно, чтобы покрыть внесённые вами изменения. Не выбрасывайте тесты старого кода без должного анализа. На первый взгляд, некоторые из этих тестов могут показаться неприменимыми к вашему новому дизайну, но стоит разобраться в причинах, по которым этот конкретный тест был добавлен.

5. Личные предпочтения и эго не должны мешать. Если что-то работает, зачем это чинить? То, что стиль или структура кода не соответствуют вашим личным предпочтениям, не является уважительной причиной для рефакторинга. Уверенность, что вы могли бы написать лучше, чем предыдущий программист, также не является веским основанием.

6. Новая технология не является достаточной причиной для рефакторинга. Одна из худших причин для рефакторинга заключается в том, что текущий код не использует все крутые технологии, которыми мы располагаем сегодня, и уверенность, что новый язык или инфраструктура могут делать вещи более элегантно. Если анализ затрат и выгод не покажет, что новый язык или структура приведут к значительным улучшениям в функциональности, удобстве обслуживания или производительности, лучше оставить всё как есть.

7. Помните, что люди ошибаются. Реструктуризация не всегда гарантирует, что новый код будет лучше или хотя бы таким же хорошим, как предыдущая версия. Это неприятно, но такова человеческая природа.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/