Код, который нас убивает

[T700]

Так и бывает. Бесконечное усложнение. Это проявляется в любом по и даже open source. И чем система становится больше, тем аккуратнее, продуманее, документированее, системнее, должен каждый следующий шаг. Это системная работа по изучению нового фунционала, его будущего использования и влияния на всю систему. Спешка тут недопустима.

[ArthurPanfilov]

Могу добавить от себя следующее - независимо от опыта специалиста и умения граммотно писать код (архитектура, паттерны, тесты и все такое) нужно еще оценивать собственную роль и обстановку в команде, в которой работаешь. Есть мнение, что если это сразу учитывать на входе, то и на выходе будет меньше разочарований.
В одном случае проще расслабить булки и плыть по течению. В другом - можно упереться и практически в одно лицо вытащить на более качественный уровень разработку. Если же заручиться поддержкой бизнеса или технических руководителей, то можно и команду вытащить на более качественный уровень. Но это уже не про написание кода.

[megahanga]

Статья хорошо отражает реалии.

[SergeyEgorov]

Чтобы не выгорать - не выгорайте :-)

Исправляйте ошибки до того, как они появились :-)

[SergeyEgorov]

Прочитал. Понимаю что возможно мне следует переключиться на абстракции... :-)

[zababurin]

По этому я свою архитектуру на работе начал писать, которая мне нужна. Это все согласованно было, никакой отсебятины. Результат. За три года из тестового проекта, проект превратился в микрофронтенды и продолжает очищаться.
У меня обратный процесс получился. Он бардака к структурированности

[dkfbm]

Всего: 60

Не обижайтесь, но боюсь, в статье речь о проектах несколько иного масштаба.

[HardlinePeak936]

Поддерживаю, у меня в голове всплыла активная ветвь «Garbage» на сотню объёмных модулей, как ирония ради психологической защиты в одном проекте...

P.s. Впрочем, там действительно было временным решением, а потому от этого избавились. Через почти полтора года.

P.p.s. Там модули от множества сервисов было, если что ;)

[Vadik_prog]

Еще хуже идеальный код с точки зрения архитектуры, но с нулевой бизнес отдачей

[megadrugo2009]

Если код ни как не влияет на бизнес - то это идеальный код.

То есть внедрение новых фич, поддержка старых, негативно не сказываются на бизнесе.

[HardlinePeak936]

Они видят функциональность, но не видят кода, думая, что новая фича — это просто добавить строчку.

Зависит от фичи и среды... В остальном — статью пролистал, а она оказалась короче, чем я ожидал ;)

[Samhuawei]

Работал в продуктовой компании которая выкатывала новый продукт раз в две недели. На одной кодобазе, но с разными отличиями для вендоров. Там техдолг составлял 30000 тикетов джиры. Но никто не парился. Заказчик платит не за архитектору, а за готовое решение. А если тикет не перешёл с техдолга в прод за год значит он никому не нужен.