Про ЭТО последнее время много пишут, вот и сегодня мне попалась заметка в ленте ITBlogs.

Надо попробовать как-то оформить накопившиеся соображения.

Нужно четко разделять рефакторинг и расширение функциональности

Проще всего объяснить это в терминах ООП: если нужно добавить еще одну реализацию уже предусмотренного в системе интерфейса, это - штатное сопровождение продукта и под термин "рефакторинг" не попадает никаким образом. Аналогично - если нужно расширить существующий интерфейс. А вот если интерфейсы нужно видоизменять, и если это к тому же сопровождается изменением бизнес-логики (то есть процессов и алгоритмов), да еще и может затронуть больше одного компонента - то это как раз оно.

Рефакторинг - это не мероприятие, а процесс

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

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

Существует популярный тезис о том что "в рефакторинге нуждается плохой код". Это поверхностное суждение: в рефакторинге нуждается любой код, который морально устарел и тормозит развитие продукта. Именно поэтому процесс должен быть непрерывным и на него всегда должен быть отвлечен определенный ресурс. Это позволит держать проект в хорошей форме (то есть быть готовым к неожиданным изменениям).

Рефакторингом нельзя решить ошибки проектирования

Если состояние проекта таково, что ведущие программисты собираются, чешут репу и говорят "надо все отрефакторить" - проект нужно выбрасывать в помойку. Серьезно.

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

В противном случае это будет сродни задаче "сделать из Волги Мерседес, заменив все детали на ходу".

Хорошее проектирование предусматривает необходимость рефакторинга

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