Законченный, якобы, проект с кривым кодом(архитектурой) - это как дом с кривым фундаментом, зачастую у него не то что низкая, у него отрицательная стоимость. То есть с нуля действительно дешевле переписать будет. Но как избежать повтора ситуации (когда вроде бы все готово, но по мелочам ничего не работает)? Для этого нужно заказчику или руководителю проекта добиватся законченных изолированных микро-решений на каждом участке (на каждой форме - диалоге - старнице). Нужно не боятся и менять первоначальные решения (просить дополнять или изменять функционалность) и смотреть как програмист будет подстраиватся под изменившиеся бизнес-требования (это реальные ситуации которые будут возникать в промышленном использовании продукта от пользователей). Если программист застревает - это и есть реальная скорость разработки проекта и признаки что проект не будет доведен до конца и выведен в эксплуатацию. А то что заказчику. там "архитекторы" накидывают код, и говорят что там все сделано и надо только дописать - это разработка нулевая или даже с минусовой стоимостью.
Ну тут как бы вот какая ситуация. Программирование такая штука, что самое страшное - это запутаться в собственном коде. В основном проекты факапятся именно из-за этого. Много программистов которые знают по чуть-чуть разные языки, апи, интерфейсы, всякие модные термины и т. п. Но очень мало программистов, которые знают их глубоко и могут организовать код так, чтобы и самим не запутаться и не запутать своих коллег. Для этого требуется опыт и умения, немного другие, чем небольшие знания языка и всяких апи. Тут нужны умения применять инструменты, рефакторинга и всяких приемов разделения проекта на части, декомпозиции.
Ну начинается проект все ок. Программист пишет - пишет вроде бы начинают появляться рабочие экраны или работающий функционал, но он не следит за чистотой кода, игнорит или не знает рекомендованные стайлгайды, стиль кода постоянно меняется, все накручивается на базовых примитивах типа for-if, нарушаются декомпозиционные сущности, рефакторинг собственного кода (для дальнейшего облегчения понимания) отсутствует (главное чтоб работал). Постоянно его костылит. И код превращается в кучу крепко завязанного, запутанного говна. Попытки внести фиксы или дополнительный функционал в такой код приводят к ещё большим проблемам. Причем снаружи - это действительно выглядит как будто что то не работает по мелочам. Но поддержка и развитие такого проекта останавливается и автору коду уже невмоготу с ним работать, потому что петля этого монолита уже крепко затянута. И человек либо тянет время и просит нанять ещё разработчиков, либо просто уходит на "лучший офер". Заказчик думает что там осталось совсем чуть чуть. И любая попытка погрузить нового программиста в этот проект проваливается.
Объясняйте заказчику, что код очень сильно запутан. Приводите упрощенные примеры запутанности и приводите примеры их решения. Воспринимайте этот запутанный проект - как челендж для себя. Думайте о том, что если вы его распутаете, поблочно перепишете и разложите все по полочкам, ваша стоимость увеличится в разы как специалиста. Оцените свои силы, научитесь жёсткому параллельному рефакторингу вместе с текущими задачами, декомпозируйте код на части, изолируйте части кода. Заказчику не произносите слово "рефакторинг". А писать с нуля - это не вариант. Вы просто протянете время и не факт, что не придёте к тому же, что сделал предыдущий разработчик. И потом свалите. Лучше научитесь плавно метаморфизировать проект при этом выполняя текущие задачи.
Причем если предыдущий автор ушел с проекта - это не самая плохая ситуация, Вы спокойно рефакторите код, перестраиваете блоки, декомпозируете сущности и как-то худо бедно выводите проект из кризиса. Но если автор ещё работает на проекте, то это ситуация гораздо сложнее, вы постоянно будете сталкиваться сопротивлением, что типа все в порядке, просто "вы не умеете работать с этим кодом" (запутанным говном), которое вам нужно "просто пофиксить", а не рефакторить и понимать.
И самый интересный финт, получается такой, что в глазах заказчика автор(источник проблем и говнокода) будет выглядеть как некий профессионал с гениальным кодом и архитектурой, код которого никто понять и поддерживать не может, потому что якобы все приходящие на проект не достаточно квалифицированы.
Да... работа такая у программиста запутанное(сложное) делать понятным(простым), а не наоборот.
Простой
