Мета-антипаттерн -- это все классические паттерны проектирования, за исключением одного (выложу сегодня его разбор в ООП и ФП в Сильных Идеях), как минимум, для джуниоров, которых однако глупейшим образом любят мучить на собеседованиях по этой темке (где в Django используется паттерн Мост?).

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

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

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

Собственно, в оригинальном учебнике "Банды четырёх" особо подчёркивается, что паттерны крайне важно использовать только в явно подходящих и оправданных сценариях. Какой-нибудь декоратор, например, может поломать вам половину всей системы, и фиг вычистишь его потом из проекта :)

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

Синхронизм: писал про очередной анти-паттерн, и пришёл вот такой вопрос в тему:

"Подскажите пожалуйста по данной ситуации обратную связь, кто прав, к то нет. Ситуация - компания разрабатывает новый микросервис для решения бизнес-задачи. Разработчики говорят, что им нужен xdebug(дебаггер для php) на prod площадке, чтобы цитата:
"Мы с XXX при переходе потратили 3 недели на исправление проблем, которые можно было решить за пол дня, если бы были средства отладки и нормальный доступ к сервисам."
Devops говорят - ребята, xdebug на prod площадке это плохо, минимум это потеря скорости сервиса в n раз.
Вопрос - должны ли девопсы включать модуль xdebug на проде для разработчиков или нет. Кто прав, а кто нет?"

Ну я тут полностью на стороне девопсов :) Потому что в частности отладка на проде это уже полный зашквар, красный флажок что нормальное тестирование не организовано, а самый правильный и продуктивный способ — это ассерты и логи вроде log4j )))
"Если код на проде упадёт" — этому мему лет 30, и кроме логов, больше ничего лучше не придумано. Кроме того, логи позволяют увидеть работу системы в динамике, что в отладчике по определению невозможно. В занятии по отладке явно подчёркиваю, что
"Отладка не имеет никакого отношения к отладчику. Первое правило отладки: не используйте отладчик".
Как быть? Ну, пройти для начала мой курс Ясное Легаси например, и придерживаться методики из занятия по отладке.

Но в данном случае конечно когда уже речь об экономии времени в десятки раз, должны менеджеры решать. Ну и что 3 недели ребята колупаются с багами, это тоже 100% ответственность начальников.

PMBoK? ITSM? Capability Maturity Model? Нет, не изучали. А я ведь годами твержу об актуальности этого всего. Короче говоря, менеджерам срочно пройти курс по одной из этих темок.

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

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

Что делать? Боссу -- срочно пройти курсы по системной инженерии.

Впрочем, когда в команде выделяется фаза "проектирования", (анти-паттерн мэйнстрим с проектированием), результат чаще всего получается гораздо более плачевный, нежели без неё :)

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

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

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

Будущее всего программирования, всеобъемлющий глобальный антипаттерн -- это JavaScript (судя например по трендам развития технологий и фреймворков в/от MMANGA/ВОТВАСЯ),

и по этой причине, наверное, лет через пять я прекращу вообще учить программированию )))

P.S. Следствие, что абсолютно обязательно сегодня знать и JS и Node.js и npm каждому программисту, желающему карьерно развиваться. Ну и TypeScript тоже, дабы это всё было не так мучительно.

P.P.S. а также React/Next.js, Sequelize, Mongoose...

+ напомню, 5 фундаментальных вещей в веб-разработке.

Шардинг -- это архитектурный антипаттерн.

Даже в проектах уровня Diablo используются и физически, и логически раздельные серверы (и базы данных) в Европе и в Северной Америке. Вы не можете использовать одного и того же персонажа и там и там. Даже ваше имя игрока нельзя перенести.

Потому что шардинг ...
a) это абсолютно обязательное знание для собеседований по теме System Design (шарды, реплики, секционирование, вертикальное/горизонтальное маштабирование... см. мои highload-курсы например), если вы настроены на серьёзное развитие карьеры, и
b) на практике, если вашей системе не нужно держать хотя бы под сотню тысяч записей в базу в секунду, забейте :)

Да, ну в твиттере например такое реализовано, но на это ушли десятки человеко-лет труда профессиональных инженеров с окладами в сотни тысяч долларов. Практически все модные highload-технологии "из коробки" без допиливания нормально работают только на тестовом стенде. А в реальной сети, где задержки, лаги, потери пакетов, джиттеры, всё это хипстерство сразу затыкается.

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

Главный инженерный антипаттерн в разработке -- это предположения.

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

Да, но на каком основании? Даже хороший опыт, и даже в схожих проектах не очень помогает, потому что практически всегда очередной проект со своей уникальной спецификой надо делать с полного нуля.

Собирайте метрики по своей работе, используйте хорошо известные прогнозные модели, и вы будете сильно удивлены, насколько математическая реальность отличается от вашего личного мнения :)

Начьните, сперва с единственной метрики: время. Делите свой проект на задачки прогнозируемой вами продолжительностью не более 1.5-2 часа, отслеживайте реально потраченное время, и сравнивайте с прогнозом, используя этот коэффициент для ваших будущих оценок.

Не получается декомпозировать таски так детально? Ну, значит, вы пока фактически вообще не умеете думать как проектировщик, пройдите мои курсы по ООАП для начала.

Сперва ваша ошибка в оценке будет составлять разы: вы будете тратить в 2-3-5-10 раз больше времени... и это нормально. Это классическая практика software engineering.

С одной стороны, я постоянно топлю за type driven development, и всегда буду это делать, потому что это абсолютный топчик. С другой стороны, надо признать, что и тут есть свой антипаттерн: лучшими специалистами тут становятся те, у кого есть хорошая и глубокая подготовка в определённых видах "высокоабстрактной" математики (например, в теории категорий или теории типов). А программисты, не интересующиеся этими темами, ну или для которых это просто сложно само по себе (и это нормально), фактически лишены возможности продуктивно развиваться в этой парадигме.

Потому что type-DD подразумевает сквозное проектирование всего пространства API так, что всё в проекте становится привязанным к определенному ракурсу, взгляду на type-level абстракции, которые придумываются на основе хорошей математики. И в результате почти сразу становится невозможным программировать без хорошего понимания этих абстракций и, главное, вычислительного "движка" их композиций, калкулусов подходящих.

И вот именно поэтому, как говорил, стратегически развиваю тему "думательных" машинок, где вся эта сложность скрыта под капотом формальных правил кодирования, которым надо просто следовать, не задумываясь особо. Это хак :)

Антипаттерн, который надо хорошо понимать абсолютно каждому ИТ-менеджеру:

Последствия рефакторинга любой крупной и сложной системы всегда непредсказуемы.

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

Есть git reset hard конечно, но когда система легаси, инфраструктуру целиком подчас откатить назад просто невозможно: например, не найти какие-то старые версии библиотек или ОС.

По этой причине любые проекты всегда веду в виртуалках, и просто слепки всего целиком храню в архивах.

Можно ли назвать антипаттерном умышленное отсутствие абстрактных статических методов, например в Java, где от них принципиально отказались? Потому что, ну вроде как мы не можем их переопределить, потому что статические методы связываются во время компиляции, а не во время выполнения.
А вот в C# 10 (.NET 6) - сюрприз - они появились.
"Once you've defined interfaces with static members, you can use those interfaces as constraints to create generic types that use operators or other static methods"

Это реально очень круто, потому что даёт качественно новую механику повторного использования кода как альтернативу тайпклассам. В тему можно поизучать "RFC FS-1043 - Extension members become available to solve operator trait constraints".

Отладка -- это, безусловно, антипаттерн.

Великолепное наблюдение Эдсгера Дейкстры: "Если вам нужны продуктивные программисты, вы быстро поймёте, что они прежде всего не должны тратить своё время на отладку; соответственно, им надо в первую очередь научиться не вносить ошибки в свой код".

Пацаны просили репост сделать :)
https://vk.com/wall-44001716_6706
До старта отборов на интенсивы по ИИ на RuCode 5.0 осталось 3 дня!
https://rucode.net/
ВСЕРОССИЙСКИЙ УЧЕБНЫЙ ФЕСТИВАЛЬ ПО ИСКУССТВЕННОМУ ИНТЕЛЛЕКТУ И ПРОГРАММИРОВАНИЮ
(говорят, бесплатно)

Сейчас довольно много софта (вроде dependabot или Unity Hub или Mongodb Atlas или фронтендерской es5-ext) внезапно превратились в зловреды: могут зашифровать весь диск, порушить проект, стереть все файлы на вашем компьютере и т. п. Схема такая, что они тянут обновления разных библиотек третьих лиц, и внутри некоторых теперь вшита вирусня, реагирующая на IP пользователя. Классическая supply chain атака с опенсорсными зависимостями, ну и не исключено, что опенсорс в России всё :)

Автоматически обновляется сейчас довольно много софта, например клиент Steam, обновления которого не отключить, и даже не знаю, что посоветовать в общем. Бди, сисадмин :)

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

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

На телефонах тем более, апгрейды нероссийских программ делать теперь потенциально опасно тоже.

Списочек вредоносного софта на данный момент, неполный конечно.

Работы программистам предстоит невпроворот :)

P.S. Сам пользуюсь платным российским антивирем (нет, не К :), где есть и защита файлов от шифрования, и защита каталогов с файлами от изменений, и хороший анализ трафика etc

Месть за Валберис ))) Вчера по всему миру случился эпичный сбой в Apple, Google, YouTube, Amazon, PayPal, Verizon, T-Mobile ... -- технических подробностей пока никаких, но будет очень интересно поразбираться в версиях (конечно заявят что-то в духе сбой электропитания бла бла бла).. Произошло это буквально через несколько часов после того, как Байден заявил (сообщает AP), что США надо срочно крепить двери кибербезопасности :)
Вот это я понимаю предупредительная ответочка по взрослому, по инфраструктурному -- сети ЦОДов ломать, а не детсадовские ддосы сайтиков и интернет-магазинов.

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

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

ИБ надо знать и уметь прежде всего в контексте System Design.

https://www.youtube.com/watch?v=SOuhTLeyVCE

Открыл новую группу по развитию ИТ-карьеры, она только для тех, кто уже работает программистом, с апреля донов из неё буду понемногу набирать на мои курсы,
и завтра (тоже только для донов конечно) выложу методичку, что надо знать минимально по ИБ, и основные пункты (фразы :), которые полезно даже просто невзначай озвучить на интервью, дабы продемонстрировать своё понимание темы.

70 тысяч айтишников (на 90% это именно программисты конечно) из России за последний месяц уехало, и в апреле ещё 100 тысяч собираются следом. Из занимающихся у меня -- где-то около 20% перебазировалось.

"Вторую волну" пока сдерживают только дорогие билеты, рост цен на жилье, а также то, что "русских никто не ждет" и "нет финансовой связности, невозможно транзакции проводить" (с) РАЭК

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

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

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

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

Ну и безусловно войти в российское ИТ уже в этом году станет значительно легче и проще, планка существенно понизится.

Кто из регионов, и пока думает "уезжать ли", рекомендую кстати тренировочную версию вашей задумки: переедьте сначала в msk/spb, тут классно и работы дофига :)

=

Знакомые рассказывают, как мучаются с "продлением" лицензий на самый разный софт (в АСУ ТП вообще швах...), который уже не купить/не продлить. Резко вырос спрос на взломщиков-крякеров, но это ведь временные решения, софт быстро устаревает, нужны свежие версии... Да и многие западные компании закономерно переходят на облачные версии с тонкими клиентами, как минимум какие-то кусочки логики делегируют серверу, ломать это бессмысленно.

=

Теперь нередко неайтишники стали спрашивать, а можно самим вот такое написать? а сколько это будет стоить?

Можно безусловно 100% реализовать любую ИТ-систему своими силами.

Но, сегодня это уже будет очень дорого и очень долго.

Единственная стратегическая мера что осталось -- развивать продуктивное обучение этому всему.

Вчера знакомые ребята, год назад немного помогал им по System Design, внезапно обратились с просьбой помочь по формальной верификации.
Я сперва не поверил своим глазам, а потом они дали ссылочку на заметку на хабре. Очень хорошая заметка кстати с полезными ссылочками, рекомендую на тг товарища подписаться, и вообще.

"...создание и доказательство безопасности формальных математических моделей средств защиты информации является обязательным шагом для прохождения сертификации продуктов от 4 уровня доверия и выше.
Что это значит простым языком? Теперь, чтобы пройти сертификацию во ФСТЭК разработчикам ПО в области информационной безопасности необходимо моделировать работу своих продуктов с помощью математических или программных решений."

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

"Я делал модель безопасности на Event-B для сертификации ФСТЭК. Делал на совесть и это было очень интересно, но это не помогло найти ошибок и описание не получилось строже и понятнее документации."

Жутко доволен таким трендом. Это сделало мой 2022-й :)
Нюанс ещё в том, что подобные услуги по понятным причинам, связанным с уровнем экспертности подрядчика, подразумевают если не миллионы долларов, то оплату на вполне западном уровне точно :)

P.S. Буду также срочно освежать мой курс по F*

Как правильно изучать теорию типов так, чтобы достаточно быстро получить практический профит?
TAPL или схожие книги не очень рекомендую для прикладных целей. Если вы миддл (раньше не надо) лучше всего начните с т.н. typestate-oriented programming -- когда мы думаем объектно-ориентированно, но не просто в терминах классов, а ещё и в терминах состояний. Каждому состоянию соответствует некоторая явная/наблюдаемая репрезентация в проекте (только не слишком увлекайтесь классическими state machines, основная абстракция тут именно first-class typestates), а методы переводят объект из текущего состояния в одно из новых допустимых.
Что поизучать:
https://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf
https://dl.acm.org/doi/10.1145/2629609

Подробнее разбираю эту тему на курсах по stateful и объектной вычислительным моделям.

Как сеньорам выживать в ИТ стратегически в современных условиях?

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

Поэтому для сеньоров схема "прийти на новую работу и вписаться в действующий коллектив" слегка теряет актуальность, а вот скилл "запилить фуллстек-проэкт любой сложности за разумную сумму" хм думаю взлетит космически.
Например сегодняшняя заметка на хабре "Как я оклад 2х хотел", где парня, претендующего на сеньора, постоянно возят по каким-то зашкварным техническим тестам, которые максимум для миддла. А вопросы вроде вычислительной сложности сортировки/поиска, это что? :) это же вообще джуниорство.

"По ощущением, ответил на процентов 70-80%. Пришел отказ."
Да, ну во-первых, конечно если претендуешь на сеньора, то и готовым надо быть реально на +30% к требуемым скиллам, это надо продемонстрировать, а не что-то миддловское.
Хотя в целом, не очень рекомендую связываться с такими мамкиными сеньорскими позициями, где от человека просто хочут хороших технических знаний и навыков.

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

Вы просто берёте ТЗ изучаете говорите срок и бюджет подписываете договор -- ну и, пацан сказал пацан сделал :)

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

Тут самый большой риск -- завязываться на других спецов. Моя схема -- делать всё ключевое самому как сеньору/тимлиду, а всю рутину отдавать джуниорам, которые прозрачно отбираются по простому чек-листу (аккуратный код + навыки достаточно быстрого решения средних задачек на литкоде; знание фреймворков вообще не актуально, кто норм решает задачки, изучит основы любого стека за пару недель), и которых, самое главное, можно быстро и безболезненно заменять в проекте на других, буквально за сутки. Такая схема достаточно хорошо масштабируется на большинство проектов среднего размера. Ну может ещё 1 уровень абстракции добавить, когда объёмная работа -- пару миддлов :) , но в целом во всех проектах лучше всего полагаться прежде всего на собственный ум.

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

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

Как подготовиться? Если вы уже давным-давно не напрягали свой ум абстрактными задачами, то начните с задачника по арифметике для первого класса, решайте всё подряд без исключения (не смейтесь, сегодня даже на уровне 1 класса многим бывает нелегко :), потом последовательно переходите ко второму классу, и т. д. Как (если) пройдёте успешно все задачи по алгебре 7-8 класс, тогда значит потенциально готовы к изучению программирования.

Как вариант, можно поиграть в разные игры "для программистов", где придётся много думать.
https://habr.com/ru/company/timeweb/blog/645593/
https://habr.com/ru/company/timeweb/blog/599835/
https://habr.com/ru/company/vdsina/blog/565032/
Пошаговые стратегии вроде HoMM на чемпионском уровне тоже неплохо.

"Проблема в том, что большинство профессий завтрашнего дня в той или иной степени связано с IT-технологиями. А они требуют фундаментального образования и системного мышления. Тут переучиться не то что сложно, а практически невозможно. Если вы до 8-го класса прогуливали математику, то компенсировать отставание будет невозможно. А уж дальнобойщику найти себя в программировании, к сожалению, нереально."
(с) Юваль Ной Харари, профессор исторического факультета Еврейского университета в Иерусалиме

У него кстати интересные, пророческие :) книги выходят,
"Homo Deus: Краткая история будущего", "21 урок для 21 века" и др.

P.S. Ну и нехудожественные книги конечно тоже важно регулярно читать.

Interfaces are abstractions
— Olaf Thielke, "Code Coach"

Interfaces are not abstractions
— Mark Seeman, "Code that Fits in Your Head", "Dependency Injection"

In software, abstraction is the process of simplifying code by finding similarities between different parts of the code and extracting shared logic into a named component
— Eric Elliott, "Composing Software and Programming JavaScript Applications"

Abstraction is a process which is used to produce generalized concepts or models, but in software we often refer to individual parts of a model as abstractions as well
— Steve Smith, "Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure"

И это сегодня пишут, на минуточку, авторитетные специалисты в computer science, авторы учебников и серьёзных научных работ, известные во всём мире преподаватели. Чьих рекомендаций придерживаться? :)

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

К счастью, если обратиться к оригинальным монографиям святых computer science 40-50-летней давности, то можно найти хорошее формальное определение абстракции от одного из величайших учёных в информатике, которое прекрасно связывает теорию с требованиями современной программной инженерии. Скоро разберу это для донов, с соответствующими прикладными выводами (как правильно думать "абстрактно", что это вообще означает), в отдельном материале в СильныхИдеях.

Когда человек заявляет: "я применил этот system design в 32 проектах, и все они оказались успешными", это явный антипаттерн.

Во-первых, отбор астронавтов в команду корабля "Аполлон-11", совершившего посадку на Луну, выполнялся отнюдь не по схеме "берём тех, у кого много классных историй успеха". Наоборот, брали тех, у кого в карьере были эпик-фейлы, но они сумели их преодолеть. Брали Выживших :)

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

Я с февраля ввёл более строгие требования к занимающимся, сейчас отчисляю где-то 50% слабаков, а с апреля, как буду понемногу делать новые наборы, планирую довести этот процент до 80%. Потому что многим прозаически не хватает характера. Отмечу кстати, что вот девушки кто у меня занимается, ну почти 100% усердные упорные трудолюбивые и добиваются хороших результатов, а вот довольно многие ребята (да и уже взрослые), хм, Илоны :) бесхарактерные и безвольные хуже капризных плаксивых девчонок.

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

P.S. Кстати, очень известные ИТ-компании, связанные с обучением в России, гордившиеся своей корпоративной культурой, трусливо сбежали, бросив своих платных учеников на произвол :) Ну понятно, погоня за долларом для капиталистов превыше всего.
Вот вам и характер (точнее, его полное отсутствие).