Не бойтесь что-нибудь сломать!
(В оригинале - Don't Be Afraid to Break Things)
Каждому, работающему в ИТ, приходилось работать на проекте, чей код был, мягко говоря, ненадежным. Любое изменение приводило к отказу в какой-нибудь другой, вообще независимой, части. Каждый раз при добавлении чего-нибудь основной целью было внести как можно меньше изменений, каждый раз затаив дыхание. Работать с таким ПО – все равно что играть в Дженгу в настоящем небоскребе, вытаскивая из конструкции несущие балки – рано или поздно такая игра закончится катастрофой.
Причина, по которой внесение изменений столь болезненно – то, что больна вся система. Системе нужен доктор, иначе ее состояние будет только ухудшаться. Вы уже знаете, что не так с вашей системой, но вы боитесь разбить яйцо, чтобы сделать яичницу. Опытный хирург знает, что при операции нужно будет резать по живому, но он также знает, что разрезы – это временно. Сразу после операции будет больно, но потом пациенту станет лучше, чем было до операции.
Не бойтесь своего кода. Кого интересует то, что какие-то части не будут работать, пока вы будете вносить изменения? Страх изменений и привел проект к столь запущеному состоянию. Инвестиции в рефакторинг окупятся многократно в течении жизни проекта. Ваша команда, поработав с «больной» системой, получила ценный опыт с точки зрения того, как система должна была быть написана правильно. Так возьмите и примените эти знания. Работать с системой, которую вы ненавидите – это не то, на что стоит тратить свое время.
Переопределите внутренние интерфейсы, переструктурируйте модули, переделайте копи-паст код и упростите дизайн, убрав ненужные зависимости. Вы можете серьезно снизить сложность, устраняя проблемные граничные случаи, часто являющиеся результатом некорректной комбинации параметров. Постепенно меняйте старую структуру на новую, постоянно тестируя результат. Попытка сделать сразу весь рефакторинг может принести достаточно проблем, чтобы вы бросили это гиблое дело на полпути до конца.
Будьте хирургом, который не боится отрезать больную часть, чтобы освободить место для здоровой. Такая позиция заразна и вскоре остальная команда присоединится к вашей инициативе по оздоровлению проекта. Список «гигиенических» процедур, которые ваша команда считает необходимыми, тоже хорошая практика в долгосрочной перспективе. Убедите руководство в том, что хотя эти процедуры и не дают сразу видимых результатов, они приведут к снижению расходов и облегчат будущие релизы. Никогда не прекращайте поддерживать код в «здоровом» состоянии.
Автор оригинала - Mike Lewis