Тупой вопрос

Иногда так, а иногда и эдак!

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

В реальном мире это как идеал, к которому нужно стремиться, но иногда и поговнокодить это хорошее решение. Главное – не копить большой техдолг.

Профилактика заболевания или доведение до терминальной стадии с героическим лечением? Многие выбирают второе, дальше суди сам.

Тупой вопрос

Да.

Чистый код, чистая архитектура? или результат в разумные сроки при приемлемом качестве исполнения?

Пожалуй тоже да.

Ну смотри, вот ты пришёл в кафе и заказываешь кофе. Тебе говорят «сейчас Вам сделают идеальный кофе». Сидишь ждёшь, 20 минут проходит, час проходит. Ты уходишь домой без кофе.

Через неделю тебе звонят и просят забрать идеальный кофе, и ещё просят с тебя 50000 рублей за эту чашку, ведь над ней всю эту неделю трудилось всё кафе.

«А мы покупаем или продаём?» (с)

Имею в команде человечка с клауд-нэйтив-эвент-дривентузией головного мозга на фоне кубернетических метастаз.
ДЫДЫДЫ, деплойабле-обзервабилити, индастриал бест-практис взахлёб.
Теперь конечно ещё MCP, аджентик эйай и другие слова приятные на ощупь языка.

Пашет как бешеный бегемот. На выходе неописуемая красота.
Но есть одна малюсенькая проблемка…
Пять лет работы на инфаркт, а кастомерам доступна функциональность, которую можно было бы «из листа цветной бумаги взявши ножницы и клей» сделать за две недели. И даже у этого то лапы ломит, то хвост отваливается.

Плохо ли это?
См. первое предложение.
Примерно восемь человек при деле, из рук в руки переходят значительные суммы. Работа кипит. Свист от струи пара периодически достигает уровня 96dB.
Благосостояние трудящих растёт накопительным итогом.

«А как же кастомеры?»
А что кастомеры?
Половина из них дармоеды, которые используют сложившуюся ситуацию, чтобы оправдывать своё безделье.
А те, кто на что-то способен, уже сами себе нарисовали нужные тулзы, вставили в уши затычки и спокойно работают.

Чистый код, чистая архитектура?

чистое бельё

Чистая совесть.

Опыт, всё познаётся через опыт. Не изучай всё сам по себе в башне из слоновой кости, а связывай свою экспертизу с людьми, чтобы и самому время найти, и люди были довольны. Есть архитекторы, которые не читали упомянутые книги и хорошо работают.

Да.

Чистая совесть, горячее сердце и холодный разум.

Эээ, а вот ты смотрел фильм субстанция? Вот и в том вопросе, о котором ты спрашиваешь, так же - на дистанции это одно и то же

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

В целом, ни то ни другое, это крайности. Важен итеративный подход - мясо наращивается постепенно.

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

«Снег без грязи – как долгая жизнь без вранья.» (c) ВСВ

Под русским ютуб-роликом «clean code horrible performance» про срач автора книги с сишником, в каменте была интересная мысль: книга была написана для времён взрывного роста IT, когда народу катастрофически не хватало, и нужно было набрать макак и быстро их выдрессировать на генерацию хоть сколько-нибудь вразумительного кода. Отсюда же и, например, жавовская экосистема: «не пытайтесь понять, как оно работает» (цитата автора книги). Но взрывной рост закончился, причём навсегда, и макаки потихоньку остаются не у дел. Жаль только что ультра-говёная экосистема, которую и невозможно понять как она работает, теперь с нами тоже навсегда.

https://cs14.pikabu.ru/post_img/big/2023/04/15/4/1681536247180865200.png :)

Ты думаешь чистый код замедляет его написание?

а, кстати, хороший вопрос.

ну код, чистый, зависит от опыта его чистота.

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

работать будет быстрее и проще, но система не бизнесовая, то-есть денег не зарабатывает.

стоит ли тратить время на её улучшения ради улучшений?

ответ, вроде как, очевиден.

Так вроде ж исходно не про преписывание. Переписывать всегда дольше и не всегда нужно.

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

Зависит от многих факторов, где-то крайне необходима чистота, а где-то и так сойдет лишь бы в сроки уложится.

Очень годное описание!

Чистые помыслы.

По моему опыту разумные сроки с расчётом на приемлемое качество необходимо ставить даже для своего хобби и пет-проектов. Иначе есть риск что дело не будет сделано никогда.

Парадоксально, но видел примеры, когда увеличение сроков, ухудшало качество разработки. Конечно, другая крайность - это когда крики, что надо было сделать вчера.

Тупой ответ - смотря для чего.

Бизнесу насрать на чистый код, ему нужен продающийся окупаемый продукт и минимальные сроки до mvp.

Критичные вещи вроде медицины, аэро и прочее могут требовать баланс, чтобы не наткнуться на последствия плохих кода и архитектуры.

Для себя и академических задач можно упороться в перфекционизм и элитарность.

Не в росте ж проблема, а в людях, которые на вопрос "почему тут статик написано?" отвечают "иначе не компилируется".

Красивый код. Всё остальное - вторично.

По моему опыту разумные сроки с расчётом на приемлемое качество необходимо ставить даже для своего хобби и пет-проектов.

Это да.

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

Это уже стопятцот раз было описано, без всякого «видел», но глабельки они видимо любимые, без похода по ним никак.

Научитесь формулировать мысли яснее.

1. смотри средний уровень у команды. Есть такие люди которые еще простой MVC не одолели.

2. для всяких стартапов будет лишняя трата времени - когда рынок застолбить надо. Сначала PoC и потом уж еженедельный рефакторинг.

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

4. Для бизнеса лучше все заранее обговорить: отсутствие архитектуры это как взять большой кредит у банка с сумасшедшими процентами. Это поднимет стоимость продукта за счет, того что придется заплатить временем-деньгами чем дальше тем больше.

5. Идеальный вылизанный софт нужен, только перфекционистам, а не заказчикам и пользователям.

Для бизнеса лучше все заранее обговорить: отсутствие архитектуры это как взять большой кредит у банка

Да, но только для успешных продуктов. Если разработка будет прекращена (по любым причинам), то долги отдавать не надо.

Отсюда проистекает выгодная стратегия, последствия коей мы все и наблюдаем: набрать максимальное количество кредитов. Если затея не удастся, то и фиг с ней, а если удастся, то будет и с чего долги отдавать.