В чём причина постоянного переделывания кода?
===============================================

 Есть заказчик, есть разработчик. Заказчик хочет чтобы разработчик сделал сложное приложение. Разработчик реализует, реализует, а затем, когда пишем "дальние" модули системы, которые базируются на первых модулях,   

код первых модулей идёт либо на переработку, либо на удаление и переосмысление, потому что неверно реализована логика или интерфейсы. И так на протяжении полугода.   

КПД получается крайне низок. Работа идёт, часы крутятся, и работа, в принципе, делается профессионально, но идёт на удаление или переделку из-за того, что что-то не так.   
  

Если вкратце: Постоянное переделывание кода проекта и отдаление релиза. В чём причина? 

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

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

 Причин много:  

1. Бизнесу всегда нужно срочно. Из-за этого менеджер/заказчик бьет по рукам и говорит "не до архитектуры и главное быстрее", по итогу — пилятся костыли, которые блинным комом накатываются и в определенный момент нужно переписывать куски структуры, чтобы просто иметь техвозможность работать дальше  

2. Если было жирно по ресурсами и времени изначально и такая проблема — не правильная архитектура, экономия на тестах и прочее  

3. Плохая договоренность и плохое понимание задачи с каждой стороны, у кого-то завышенные/заниженные ожидания (один сказал сделай мне приложение, второй сказал, что сделает — вина обоих в таком случае)  

4. Не всегда это плохо. Сначала быстро запустили (проверили гипотезу, получили первые деньги, инвестиции и прочее), потом **переделывают планово** (просто этот план может не проговорен, отсюда плохие ожидания и чувство низкого КПД, а он может высокий как раз).  
  

Всегда, всегда ошибка менеджмента — где-то договорились, где-то не оговорили что-то, где-то не учли, где-то нажали, где-то пренебрегли, не выяснили ожидания, где-то сэкономили на выборе разраба, и прочее,  
**даже если взяли не умного разраба — это тоже вина менеджмента**  
  
**UPD:** [Urukhayy](http://toster.ru/user/Urukhayy) речь не об этом проекте?  

[Может ли проект быть собран с низким качеством кода, и пользоваться большим спросом?](https://toster.ru/q/484319) 

> Постоянное переделывание кода проекта и отдаление релиза. В чём причина?

 В том, что проект живой. Так и должно быть.  

Постоянные изменения и уточнения требований во время разработки (если она длительная) и поддержки проекта - это нормально.  
  

Читайте про распространенные жизненные циклы: <https://habrahabr.ru/company/edison/blog/269789/>  
  

Половина ответов под вашим вопросом - люди совсем не понимают, что пишут,из-за отсутствия опыта, предполагая, что можно сделать waterfall для большого проекта. 

> Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.  
> 
> <https://www.inpearls.ru/>

 - © Михаил Жванецкий 

 в незнании парадигмы разработки ПО. писать код - вообще предпредпредпоследнее (!) дело.   
  

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

 В неумении разработчика проектировать гибкую архитектуру приложения и писать расширяемый код. 

> Заказчик хочет чтобы разработчик сделал сложное приложение.

  
**Причина 1**: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").  
  

> КПД получается крайне низок.

  
**Причина 2**: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.  
  

> но идёт на удаление или переделку из-за того, что что-то не так. 

  
**Причина/особенность 3**: иногда это неизбежно: бизнес меняется, потребности - тоже.  

Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о [стоимости ошибок](https://www.stickyminds.com/article/what-cost-requirement-error) на разных этапах разработки.  
  
**Причина 4**: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на **гарантированные** переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу. 

 Типичный пример:  
  

Была штука, которая слала сообщение в десктопное приложение с сообщением о текущем состоянии системы. Работала она так 3 года, все было окей с ней.  
  

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

Получилась ситуация, что:  
  
* Бекенд так отдавать не мог
* Чат-сервер такие сообщения не пропускал
* Десктопное приложение группировку не могу нормально отобразить

  
  

В итоге, из-за одной новой штуки пошли переделки в трех ключевых модулях системы. 

 Карл Вигерс "Разработка требований к программному обеспечению"  
**скриншот первой страницы первой главы — про вас**![5a4e46fe7d045170343260.png](https://habrastorage.org/webt/5a/4e/46/5a4e46fe7d045170343260.png) 

 это норма 

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

А у вас, похоже, методологии нет, что приводит к неэффективной трате средств вашим заказчиком.