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

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

Если вкратце: Постоянное переделывание кода проекта и отдаление релиза. В чём причина?
  • Вопрос задан
  • 1964 просмотра
Пригласить эксперта
Ответы на вопрос 9
search
@search
мама говорит что я особенный
На самом деле, рефакторинг - это неотъемлемый элемент процесса разработки. Без него никак. На поздних этапах обязательно всплывают неучтенные подробности. К тому же сам разработчик развивается и стремится улучшить то, что было написано несколькими месяцами ранее.

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

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

UPD: Urukhayy речь не об этом проекте?
Может ли проект быть собран с низким качеством кода, и пользоваться большим спросом?
Ответ написан
Комментировать
titov_andrei
@titov_andrei
All my life I learn - and die a fool!
Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.
https://www.inpearls.ru/
- © Михаил Жванецкий
Ответ написан
Комментировать
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
В неумении разработчика проектировать гибкую архитектуру приложения и писать расширяемый код.
Ответ написан
Заказчик хочет чтобы разработчик сделал сложное приложение.

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

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

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

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

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

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

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

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

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

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


В итоге, из-за одной новой штуки пошли переделки в трех ключевых модулях системы.
Ответ написан
Комментировать
AlexanderYudakov
@AlexanderYudakov
C#, 1С, Android, TypeScript
Карл Вигерс "Разработка требований к программному обеспечению"
скриншот первой страницы первой главы — про вас
5a4e46fe7d045170343260.png
Ответ написан
Комментировать
vicodin
@vicodin
Имею некоторый опыт
это норма
Ответ написан
Комментировать
Andrey_Pletenev
@Andrey_Pletenev
Pletenev.com
Насколько можно судить по вашему вопросу, причина в том, что у вас нет целостного подхода к разработке. Если вы не хотите много переделывать, работайте по "водопаду": наймите адекватного архитектора и проектируйте всю систему перед кодированием. А если вы не хотите/не умеете/не можете проектировать заранее, тогда уж следуйте эджайлу. При этом у вас переделки останутся, но хотя бы релизы станут короткими.
А у вас, похоже, методологии нет, что приводит к неэффективной трате средств вашим заказчиком.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы