Дело не в том, что он типа тупой - он реально сеньор. Просто из-за такой культуры (безнес-ориентрование) люди не утруждают себя соответствию минимальным “культурным” аспектам

Ему просто не до головы поискать как делать правильно, а начальство епамовское его не дрючит, потому что он не в епаме

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

вообще приемлимая реализация. В чем вообще приемущества безусловного соблюдения реста? я как-то на собесе замешкался на вопрос про разницу пост/пут просто потому, что никогда не задавался этим вопросом... и если ты давно уже прочитал первый ответ на стэковефлоу ты уже сеньернее? и вообще так-то похер для решения задачи на эту разницу, все равно создавать новые или полностью заменять существующие сущности по PUT это ебаное решение и никто так не делает, зато соотвествует REST

Потому что в ДЗ сказано “сделай рест круд”

Реальная жизнь такая, что на старте проекта нет времени писать правильный код. И именно так вырастаетрастет бизнес (низкие косты и быстрая адаптация к рынку). А когда он уже вырос можно затыкать дыры. И это нормально.

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

При этом сейчас у нас есть и участки куда без 120 комментариев в PR код не попадет. Потому что благодаря всем деньгам заработанным тогда мы можем себе это позволить.

Качество кода не так сильно влияет на бизнес, как возможность быстро реагировать на изменения среды

Не нужно управлять моторной лодкой как круизным кораблем и не нужно строить круизный корабль чтобы переплыть через двухкилометровое озеро

а с другой стороны - так ли уж важно наяривать на идеальный код, точные байтики и микрооптимизации там, где этого реально не требуется? просто, кмк, везде баланс должен быть. были случаи и когда упоротость некоторых лидов при проектировании идеальной (с их точки зрения) архитектуры, побивание палками на ревью всех вокруг и всё такое приводило к тому, что в проекте один фиг без поллитры не разобраться. мне кажется, нужно делать не "правильней", а "проще". если излишних оптимизаций не требуется - сделай проще, не закладывай расширяемость всего и вся на будущее там, где не факт что оно нужно. скопипасть этот модуль, надо будет - объединишь позже. напиши какие-нибудь тесты, лишь бы работали, а не гонись за идеально расписанными контекстами и покрытием 99%. мне кажется, у нас в снг с этим в обратную сторону перегибают часто (хоть и не везде)

Плюсую, видел такое не раз. Многие часто путают понятие хороший код с "модный подход который я вчера видел на коференции".

Для меня, например, хороший код - это код, который не требует поддержки или минимизирует ее стоимость.

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

Ты тут имхо приравнял правильный = overengineered и кстати часто так и бывает когда говорят "правильный код".

ну я примерно про это, да. когда в условном ООП-коде всё пытаются на 100% к солиду привести например

Это вопрос культуры.

Человек либо знает как быстро найти правильное решение, либо впринципе знает правильное решение. После находления хуячит.
Либо он просто сразу хуячит, не задумываясь о последствиях, оправдывая это “гибкостью”.

Ты можешь есть вилкой или ножом а можешь руками - количество вырабатываемого тобой говна от этого не изменится

Так вот в стартапах типа всем “насрать” на нож и вилку. И поэтому тутошние спецы просто не умеют ими пользоваться

Кстати для меня лично red flag такой когда в требованиях к вакансии указано: твердое знание принципов SOLID - так, стоп, похоже лютый overengineering будет :D

не, могут по инерции писать просто

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

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

Лучше всего просто использовать direct approach и опыт "как не вствпить в говно" с прошлого

@andrew_dryga 👍