ну типа "паттерн модуль", "паттерн hoc", "паттерн чистая функция"

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

реальная история есличо, там правда был бекендер, да еще и зеленый

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

У меня тоже есть пример. Я пришел на новую работу, первый день. Тимлид мне говорит, что учить паттерны вредно, у нас не такой большой проект, поэтому мы ничего не используем а пишем фичи максимально быстро.
Я такой "ок", настраиваю инфраструктуру и тут падает прод. Причем никаких логов нет. Вся команда бекендеров начинается выяснять почему так и выясняется, что при деплое кто-то неправильно указал токен для сентри и тот валился с ошибкой. Поправили и внезапно прод поднялся. Убрали токен (правда уже на стейджинге) - стейджинг упал.

2 дня выясняли в чем дело, Тимлид все другие задачи из спринта убрал. В конце концов выяснили:

Тимлид за 15 минут написал обертку для логгера и ещё за 15 сервис, который отдавал статьи с сайта. Сервис который отдавал статьи использовал логгер, что логично. Проблема в том, что логгер отдавал данный о пользователе(!) которые сервис, который отдаете статьи(!) передавал в сервис авторизации(!).

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

Если бы просто изначально это решили сделать иначе, а не за 15 минут - то потратили бы 2 часа. Но в итоге суммарно было потрачено 30 минут + 2 дня фуллтайм изысканий 4х бекендеров.

😱

1. Разумеется подразумевается. Но если мы говорим о самостоятельном обучении с небольшим контролем тимлида, это КРАЙНЕ СЛОЖНО разобрать.

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

Разумеется если хуяк хуяк то случаются чаще, чего уж тут таить.

Я понимаю что Вы считаете себя абсолютно правым и самым умным в "если бы просто изначально решили сделать иначе". Но это нефига не так, задним умом все крепки.

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

Ну я вижу, что изучение паттернов оно как минимум учит не смешивать все в один котел. Более того, аргумент "Для практики вредно" так же привносит кучу бед. То есть здесь вопрос о дисциплине в разработке ПО.

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

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

Хотя согласен, изучение паттернов конкретным тимлидом могло бы эту проблему конкретно здесь предотвратить, но все таки это не root cause

@xanf_ua переслал email квитанцию на illya@javascript.ninja , но инвайт в teregram группу еще не получил

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

Но вообще я с Вами согласен на счет того, что это индивидуальный кейс который не всегда ложится на реалии

Почему мне этот пример не нравится: любой инцидент это вообще комплексная штука, в которой всегда задействовано множество звеньев. И обычно последнее звено это человек который накосячил потому что чего-то не знал или устал.
Разумеется можно делать выводы из инцидентов в духе "все плохо потому что Вася не знал. Все плохо, Васи должны знать!". Но в большинстве случаев (не всегда) это контрпродуктивно и винить конкретного Васю за провал не стоит. Тут я возможно вижу вину тимлида но не в незнании паттернов, а в том что он не нашел правильный баланс между скоростью разработки и надежностью системы. (Или нашел? Кто его ваш бизнес знает... )

Вообще я себе сейчас нашел отличное развлекательное чтиво в свободное время, может кому любопытно будет)

Вот и я о том же. Я о том, что должен быть баланс и к этому балансу нужно приучать сразу. А категоричное "Нужно обязательно учить" или "Для начала не нужно учить" мне не нравится.

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

Мне проще написать "паттерны хуйня, пруфов не будет". =)