Рефакторинг легаси: как не сломать то, что работает
В прошлом году мне досталась задача, которую многие разработчики боятся больше, чем писать код с нуля: привести в порядок модуль оплаты, которому было пять лет, без тестов и с единственным человеком в компании, который хоть немного помнил, как он устроен — и этот человек уже уволился. Вот к каким выводам я пришёл по итогам этой работы.
Первое правило: сначала понять, потом менять
Соблазн сразу начать переписывать код, который выглядит плохо, очень велик. Но за уродливым на первый взгляд кодом почти всегда стоит история — часто это накопленные исправления реальных багов и обработка граничных случаев, которые не видны из чтения кода поверхностно. Прежде чем менять что-то, я потратил неделю просто на чтение: git blame по ключевым файлам, старые тикеты, связанные с этим кодом, комментарии в коммитах.
