Планируя рефакторинг заранее, вы должны четко понимать, что именно хотите исправить. Очень часто один небольшой рефакторинг выливается в часы или недели дополнительных исправлений, которых никто не планировал. Если вы поняли, что, начав рефакторинг, уходите все глубже, захватывая все новые и новые части системы, – остановитесь и решите, где на данный момент нужно поставить точку. Вы не должны ставить под угрозу всю работу над проектом, а к рефакторингу всегда сможете вернуться и позже.
Приступайте к рефакторингу только в том случае, если сможете точно проверить, выполняет ли исправленный код те же функции, что и прежде. Лучший и самый простой способ для этого – тестирование тех частей кода, которые подлежат исправлению. Если тесты для них отсутствуют, не пожалейте времени и напишите их до рефакторинга.
При рефакторинге обращайте внимание на любые детали кода, над которым работаете. Что-то незначительное, то, что вы сочли устаревшим и ненужным, может оказаться критически важным при каком-либо из сценариев работы, поэтому проверяйте, проверяйте и еще раз проверяйте работу кода после рефакторинга.
Приступая к рефакторингу, заручитесь поддержкой кого-то из старших разработчиков и коллег или как минимум обговорите с ними, что хотите исправить. Возможно, вы видите в коде больше проблем, чем есть на самом деле. Разработчикам свойствен перфекционизм, и иногда это скорее проклятие, чем дар.
Тезисы
■ Регулярный рефакторинг обязателен.
■ Убедитесь, что рефакторинг определенного кода действительно необходим.
■ Планируйте рефакторинг и его границы.
■ Проверяйте, проверяйте и проверяйте код после рефакторинга; он должен работать точно так же, как и до него.
■ Не позволяйте перфекционизму утянуть вас на дно, вовремя останавливайтесь.
Задание
Проанализируйте код вашего проекта. Можете использовать linters или проверить код вручную, просто читая его. Найдите проблемные или устаревшие области, которые требуют обновления. Попытайтесь определить границы рефакторинга этих областей кода, проверьте, существуют ли для них тесты. Обговорите возможный рефакторинг со старшими разработчиками или менеджерами – возможно, вам выделят время, которое вы сможете потратить на улучшение проекта.
История из жизни
Однажды я сорвал запуск проекта, потому что неверно оценил время рефакторинга в 2–4 часа. В итоге на него ушло 2,5 недели.
Работает – не трогай
Вы нередко будете сталкиваться с кодом, который выглядит не так, как должен выглядеть хороший код. Возможно, он будет плохо отформатирован или сложен и запутан, и вы почувствуете непреодолимое желание провести рефакторинг. Может быть, вам захочется обновить не сам код, а версии библиотек, используемых в приложении.
Остановитесь и задумайтесь – какую проблему вы хотите этим решить? Если вами движет исключительно чувство прекрасного или желание иметь самые свежие версии, подумайте еще раз. Если ваш проект уже находится в продакшн-стадии и его используют клиенты, если он выполняет свои функции так, как надо, и вы просто хотите навести лоск, то лучше взвесить за и против.
Случаи, когда невинное обновление одной библиотеки приводило к сбою работы всей системы, не пересчитать по пальцам рук всей вашей команды разработчиков. В попытке улучшить все что можно и что нельзя вы нередко можете только все испортить.
Обновление проекта и его улучшение – сложный процесс, влекущий за собой риски, которые вы должны как минимум брать в расчет, а как максимум – иметь смелость нести за них ответственность. Золотое правило «работает – не трогай» звучит забавно, но за ним скрыты многие часы внеурочной работы и стресса разработчиков, системных администраторов, проджект-менеджеров и тестировщиков. Вам, как профессионалу, важно поддерживать проект в рабочем состоянии, даже если он слегка устарел или не использует самых новых инструментов.
Проводите обновления постепенно, дополняйте их проверками, тестами и своей здравой логикой. Старайтесь не ломать то, что работает правильно, даже если оно выглядит не так классно, как вам бы хотелось. Вы всегда сможете вернуться к этому вопросу позже.