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

Question

[Urukhayy]

Есть заказчик, есть разработчик. Заказчик хочет чтобы разработчик сделал сложное приложение. Разработчик реализует, реализует, а затем, когда пишем "дальние" модули системы, которые базируются на первых модулях,
код первых модулей идёт либо на переработку, либо на удаление и переосмысление, потому что неверно реализована логика или интерфейсы. И так на протяжении полугода.
КПД получается крайне низок. Работа идёт, часы крутятся, и работа, в принципе, делается профессионально, но идёт на удаление или переделку из-за того, что что-то не так.

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

Comments

[AlikDex]

вы просто релизните чо есть. а потом будет столько допилов, что спать некогда будет ;D
Причем не важно на какой стадии вы релизните свою детище, даже если оно готово по вашим меркам на 100% все равно придется 20-30% доделывать а то и передывать вообще. Так чта думаю 50% готово?! в продакшен, там по ходу докостыляете и будете рефакторить потихой.

Answer 1

[Demian Smith]

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

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

Comments

[timurkin]

Лентяй, бизнес не должен оплачивать рефакторинг? Смешно :)

[Demian Smith]

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

[Demian Smith]

Лентяй, ну если программист может объяснить бизнесу зачем это нужно, то всё ОК )) Как говорил Эйнштейн: "если ты не можешь объяснить ребёнку чем занимаешься, то хернёй ненужной ты занимаешься".

[Dark Hole]

Лентяй, Эйнштейн мог объяснить, чем он заниимался)

[Demian Smith]

Dark Hole, есть фильм, в котором Эйнштейн показал ребёнку как работает гравитация, подбросив яйцо с балкона. После этого сказал что именно это он и изучает :-)

Answer 2

[Максим Федоров]

Причин много:
1. Бизнесу всегда нужно срочно. Из-за этого менеджер/заказчик бьет по рукам и говорит "не до архитектуры и главное быстрее", по итогу — пилятся костыли, которые блинным комом накатываются и в определенный момент нужно переписывать куски структуры, чтобы просто иметь техвозможность работать дальше
2. Если было жирно по ресурсами и времени изначально и такая проблема — не правильная архитектура, экономия на тестах и прочее
3. Плохая договоренность и плохое понимание задачи с каждой стороны, у кого-то завышенные/заниженные ожидания (один сказал сделай мне приложение, второй сказал, что сделает — вина обоих в таком случае)
4. Не всегда это плохо. Сначала быстро запустили (проверили гипотезу, получили первые деньги, инвестиции и прочее), потом переделывают планово (просто этот план может не проговорен, отсюда плохие ожидания и чувство низкого КПД, а он может высокий как раз).

Всегда, всегда ошибка менеджмента — где-то договорились, где-то не оговорили что-то, где-то не учли, где-то нажали, где-то пренебрегли, не выяснили ожидания, где-то сэкономили на выборе разраба, и прочее,
даже если взяли не умного разраба — это тоже вина менеджмента

UPD: Urukhayy речь не об этом проекте?
Может ли проект быть собран с низким качеством кода, и пользоваться большим спросом?

Answer 3

[Андрей Титов]

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

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

Answer 4

[Сергей Горностаев]

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

Comments

[Ильдар В]

ну не всегда. Иногда заказчик внезапно решает, что ему нужно совершенно противоположное. Или что часть системы вообще не нужна. Часто заказчик сам не знает чего хочет

[Сергей Горностаев]

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

Answer 5

[Станислав Макаров]

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

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

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

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

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

Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

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

Answer 6

[Сергей Нижний Новгород]

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

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

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

Получилась ситуация, что:

• Бекенд так отдавать не мог
  
• Чат-сервер такие сообщения не пропускал
  
• Десктопное приложение группировку не могу нормально отобразить
  

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

Answer 7

[Александр Юдаков]

Карл Вигерс "Разработка требований к программному обеспечению"

скриншот первой страницы первой главы — про вас

Answer 8

[Anton Filippov]

это норма

Answer 9

[Андрей Плетенев]

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