Как делать глубокий рефакторинг ПО, если нельзя останавливать разработку?
Уже более N числа лет идет разработка приложения. Им уже пользуются. Разработка идет по 2 недели, в конце которых происходит демо перед заказчиком - показываем что сделано. И вот нельзя ничего не показать. А в коде уже каша.
Что делать?
Где есть информация как правильно разрабатывать ПО чтобы такого не было?
Как выпутаться из этой проблемы?
Для решения таких проблем и появились такие практики как TDD (разработка ЧЕРЕЗ тестирвоание) -- то есть не полное покрытие тестами, а строго сначала тест, потом реализация, и потом рефакторинг как разработки, а не как реакция...
Потому когда что-то резко меняется -- вы не боитесь менять, так все покрыто абсолютно тестами...
Для больших проектов и групп и проектов моих навыков недостаточно, потому я ухожу наблюдать... и выдал то, что увидел общего между вашей и моей проблемами
Выпутаться - никак, рефакторинг всегда будет нужен, не бывает идеальной программы/кода. Мы выпутываемся потихоньку, не берёмся за глобальные переделки - это зло, рефакторинг должен происходить именно по мелким частям, и чем меньше изменение тем лучше, каждый раз вы всё ближе к цели, а код всё чище. Если вам дают новую фичу - не стесняйтесь сказать, что для этого мне надо переделать то-то и чуть завысить сроки, выделив себе немного времени для рефакторинга, никто от этого не умрёт.
Сложность, запутанность кода -> одно из естественных следствий развития проекта.
Как держать сложность в разумных предлах - об этом все эти ООП, SOLID, микросервисная архитектура и тд.
Но суть везде схожая -> разделить один запутанный код на независимые части (функциональные блоки, модули, микросервисы), которые проще понять, проще развивать, переиспользовать, переделывать, или вообще заменять другими модулями.
Святослав, ну да постоянно это делаю что-то удаляется, что-то добавляется, что-то переписывается или упаковывается в другие сущности, если постепенно это делаешь, постепенно улучшаешь продукт, этот процесс идет непрерывно, в этом и заключается развитие продукта.
Инногда на этом может потребоваться целый этап работ, а то и больше, что поделать, нужно значит выделить этот этап, а не затягивать, нет смысла развивать тот код который вы собираетесь УЖЕ сейчас переделывать, чем больше вы развиваете то что требует переделки, тем дороже вам потом это все переделывать прийдется.
Есть даже правило такое -> любые НЕОБХОДИМЫЕ изменения нужно вносить немедленно, тк потом делать это будет сложнее и дороже.
По поводу заказчиков -> которые обязательно нужно что-то показать. Если ему подрядчик говорит что нужно провести модификацию кода для дальнейшего развития проекта, ЗНАЧИТ нужно провести. Заказчику следует доверится, и оплатить этот этап и подождать еще недельку другую, до того как перейдете к дальнейшим плановым работам, не в его интересах в погоне за видимыми фитчами превращать проект в абсолютно не поддерживаемый и не развиваемый продукт, с которого разработчики сбегать будут.
Нужно объяснить что это естественный процесс, и на разных этапах время от времени будет требоваться работы по реорганизации вашего кода, обновлению подходов, улучшению организации кода и что это тоже стоит денег и это необходимо делать.
Рефакторинг не заложить заранее.
