Есть мнение (весьма радикальное), что абсолютно любой проект рано или поздно скатится в г (если, конечно, не закроется раньше). И полностью избежать такого финала невозможно. Но можно максимально его оттянуть. Для этого не нужно писать без багов - это из области фантастики.
Можно провести аналогию между рефакторингом и уборкой квартиры. Вот когда надо начать убираться? Когда станет трудно зайти в дом? Или когда будут заносить новую мебель?) А давайте каждый, живущий в ней, будет убираться только там, где считает нужным и как считает нужным?
Я сейчас привел два самых распространенных, на мой взгляд, заблуждения относительно рефакторинга. Первое - рефракторим только по факту добавления фичи. Выглядит очень соблазнительно. Особенно тем, что пахнет избежание преждевременной оптимизации.
"Да, есть плохой код. Но что сейчас его трогать, если он пока никому не мешает? Вот затронет он фичу, зарефакторим." Это такой себе ad hoc-рефакторинг под конкретные кейсы.
Второе заблуждение: глобальный рефакторинг не нужен, разработчики должны самостоятельно прибираться везде, где увидят. Соблазнительно снятием ответственности с лида и менеджера. Такая себе приятная иллюзия анархии, в которой должен рождаться порядок.
Только вот он не родится. Где два программиста, там, нередко, три архитектурных видения. А когда программистов 5 или 10? И каждый будет рефакторить в своем видении. При этом разработчики часто могут быть не вовлечены в глобальные планы по развитию проекта.
И могут не иметь представления о том, что в ближайшем или не очень будущем в проект планируется добавить, а что будет гарантированно убрано. Но рефакторят, как видят. Благое начинание, но оно только ускорит приход состояния "Г."
Ad hoc рефакторинг опасен ровно таким же ситуативным и бессистемным внедрением в код, который никем, по сути, не управляется. В итоге порядок и способ внедрения фич начинают диктовать архитектуру. А не наоборот. Итог предсказуем.
Сергей Нагаев