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

[@T700]

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

[@ArthurPanfilov]

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

[@megahanga]

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

[@pravosleva]

Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.

Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )

Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.

[@SergeyEgorov]

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

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

[@pravosleva]

Попробуйте прочитать ещё раз. Возможно не с первого раза, но что-то новое без сомнения должно открыться. Главное, не останавливайтесь на полпути )

[@SergeyEgorov]

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

[@pravosleva]

Отличное начало

[@zababurin]

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

[@dkfbm]

Всего: 60

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

[@HardlinePeak936]

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

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

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

[@Vadik_prog]

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

[@megadrugo2009]

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

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

[@HardlinePeak936]

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

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

[@Samhuawei]

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