Рефакторинг кода: зачем менять то, что работает

Рефакторингом кода Мартин Фаулер, автор книги с таким названием, называет изменение внутреннего устройства программы, после которого её проще понимать и дешевле менять. Всё, что видят клиенты, после рефакторинга работает как прежде. Меняется то, с чем имеют дело разработчики.

Правило скидки в пяти местах

Допустим, скидка для оптовых клиентов считается в интернет-магазине в пяти местах: в корзине, в счёте, в выгрузке в 1С, в мобильном приложении и в отчёте для отдела продаж. Когда условия скидки меняют, разработчик правит и проверяет все пять, и однажды одно место забывают. В счёте старая скидка, в 1С новая, и бухгалтерия неделю выясняет, откуда расхождение. Числа условные, подставьте свои.

Рефакторинг здесь — собрать правило в одно место, откуда его берут все пять. Клиенты ничего не заметят, зато следующая смена условий займёт одну правку. Окупается это, только если правило и правда меняют. Скидку не трогали три года и не собираются? Тогда переделывать работающий код незачем, и рефакторинг без такой причины мы не продаём.

Когда рефакторинг лучше, чем переписать с нуля

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

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

Без автоматических тестов рефакторинг опасен, потому что проверить, что поведение не изменилось, нечем. Поэтому начинают с тестов на самые важные пути, например оплату. С чего начать в вашем продукте, покажет аудит кода.

Вопросы о рефакторинге