@krakaka

Бизнес и продажа фичей важнее качества кодовой базы?

Речь идет о web разработке. Все встречающиеся мне компании больше уделяют времени менеджменту и продажам, росту пользователей, чем кодовой базе. Все встречающиеся мне проекты имели плохую кодовую базу, я имел дело с СНГ и зарубежными проектами. Большие бизнес приложения выполнены по большей части в процедурном стиле конструкциями if-else, усеянными бесчисленными комментариями с ссылками на задачи. Отсюда вытекает большое число негативных последствий, которые и подрывают этот самый бизнес пропорционально движению по графику технического долга в сторону застоя.
  • Вопрос задан
  • 214 просмотров
Решения вопроса 2
Zoominger
@Zoominger
System Engineer
Лол. Поздравляю с прозрением. Программист (админ, юрист, whatever) - это всего лишь специально обученная мартышка, а заправляет всем менеджмент. Так было, так есть, и так будет, и топу вообще плевать, что процедурные конструкции оскорбляют нежные чувства какого-то челика, который сегодня тут, а завтра уже нет.

P. S. На всякий случай отвечу отдельно - ответ на вопрос из заголовка: "Да".
Ответ написан
vabka
@vabka
Токсичный шарпист
Бизнес и продажа фичей важнее качества кодовой базы?

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

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

Вероятно, проблема в том, где вы работаете. Причиной может быть низкая культура разработки и легаси.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@mimocrocodil
Есть такое понятие - "технический долг". Суть в том, что если своевременно не сокращать, по нему могут набежать большие "проценты". Выражаться это может к срыву сроков, большому количеству багов, хрупкости системы и сложности понимания для пользователя, стоимости эксплуатации, выгоранию сотрудников и так далее. Часто бывает необходимо "взять в долг", но так же важно вовремя его "отдавать". Если вы ранее не сталкивались с этим понятием, рекомендую почитать первоисточники.

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

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

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

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