6/97: Прежде, чем вы приступите к рефакторингу

Это перевод Before You Refactor. Автор: Rajith Attapattu.

Из "97-ми вещей, которые должен знать каждый программист".

В какой-то момент любой программист сталкивается с необходимостью улучшить свой код - рефакторингом. Но прежде чем вы приступите к этому, пожалуйста, подумайте о следующих вещах, потому что они помогут вам и другим сэкономить кучу времени (и страданий):

• Наилучший способ к реструктуризации кода начинается с взятия существующей базы кода и тестов, написанных для неё. Это поможет вам понять сильные и слабые стороны существующего кода, так что вы сможете гарантировать, что вы сохраните сильные стороны, избегая ошибок, приводящим к слабым сторонам. Все мы думаем, что сможем написать лучше, чем существующая система... пока в итоге мы не окажемся с чем-то не лучшим (или даже худшим), чем предыдущая инкарнация, потому что мы не учились на ошибках старой системы.
• Избегайте искушения переписывания с нуля. Лучше всего использовать повторно так много кода, как это возможно. Не важно, что этот код уродлив - он уже был протестирован, проанализирован, и т.п. Выкидывание старого кода (особенно, если он побывал в релизных версиях) означает, что вы выкидываете месяцы (или даже года) проверенного, закалённого боями кода, который может содержать в себе обходные пути или исправления, о которых вы даже не подозреваете. Если вы не примете это во внимание, то ваш новый код может в итоге демонстрировать те же самые загадочные баги, что уже были когда-то исправлены в старом коде. Вы выкинете в мусорку много времени, усилий и полученного знания за всё это время.
• Много последовательных изменений лучше, чем одно массивное изменение. Последовательные изменения позволяют вам просто измерять их влияние на систему - к примеру, через тесты. Вам будет не смешно, когда вы увидите сотни красных отметок в тестах после одного большого изменения. Это может привести к разочарованию, которое может привести к неверным решениям. С другой стороны, вы легко справитесь с парочкой проваленных тестов.
• После каждой итерации - убедитесь, что все тесты проходят. Добавьте новые тесты, если существующие не покрывают ваши изменения. Не выкидывайте тесты от старого кода без внимательного изучения. С первого взгляда, некоторые тесты могут казаться неприменимыми к вашему новому дизайну, но будет очень мудро покопаться в причинах, почему этот тест был изначально добавлен и что он должен проверять.
• Личные предпочтения и эго не должны стоять у вас на пути. Если что-то не сломалось - зачем это чинить? Если стиль или структура кода не соответствуют вашим личным предпочтениям - то это не должно быть причиной для реструктуризации. Если вы думаете, что вы можете написать этот код лучше, чем предыдущий программист - это тоже не достаточная причина.
• Новые технологии - это не достаточная причина для рефакторинга. Одна из наихудших причин для рефакторинга - это если существующий код не следует всем этим новым клёвым технологиям и веяниям сегодняшнего дня, и мы верим, что новый язык или библиотека могут сделать наш код более элегантным. Если только анализ стоимости и выгоды не покажет вам, что эти новые вещи приведут к значительным улучшениям в функциональности, управляемости или продуктивности, то лучше бы вам оставить всё как есть.
• Не забывайте, что люди делают ошибки. Реструктуризация не гарантирует, что новый код всегда будет лучше старого (или хотя бы так же хорош как он). Я видел и был частью нескольких неудачных попыток реструктуризации. Это не было красиво, но это было человечно.