Почему мы боимся непрерывного рефакторинга?

Непрерывный рефакторинг полезно проводить по многим причинам. По сути, это разумный вклад в общее состояние кода. По каким же причинам мы боимся рефакторинга? Что может помешать изменениям?

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

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

Среди остальных причин:
1. Недостаточно времени во время разработки. Вот в чем загвоздка: знание о предметной области и недостатках существующего кода приходит с опытом - в конце итерации или цикла выпуска.

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

Ваш код отображает состояние ПО на данный момент. Это постоянный процесс - он заканчивается только, когда продукт перестает существовать или сопровождаться.

2. Нехватка целенаправленных усилий для преобразования знания предметной области в существующий код. По мере продвижения проекта разработчики больше узнают о предметной области и пробелах в своих знаниях.

Преимущественно, они проявляются в: избыточных абстракциях, недостаточной гибкости с известными вариациями в предметной области и отсутствие концепций, относящихся к предметной области и смоделированных в виде объектов первого класса (first-class citizens).

3. Недостаточные знания инструментов рефакторинга (к примеру, в Eclipse существует множество таких инструментов).

4. Незнание тактик рефакторинга - перемещение методов, создание интерфейсов, замена логики if...then ("если...то") и т.д. - необходимых для поддержания кодовой базы в аккуратном состоянии.

5. Нежелание постоянно совершенствовать кодовую базу.

источник