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

Ну блин, ребята, почитайте хотя бы "От математики к обобщенному программированию" Степанова (как правильно проектировать библиотеки наподобие STL C++), это уровень недо-джуниора.

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

Проблема с обучением детишек программированию заключается в том, что последующая работа в индустрии неизбежно превратит детское увлечение в нечто невесёлое.
https://store.steampowered.com/app/1386180/Bitty_Engine/

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

Классная исследовательская группа в духе легендарной Xerox PARC, занимающаяся очеловечиванием компьютеров + планы на ближайшие 50 лет (Алан Кэй одобрил). В сравнении с Dynamicland современные смартфоны -- это тюрьма, как выразился один из позанимавшихся там.
https://dynamicland.org/

Конец света в ИТ быстро настанет, когда в компиляторах начнут активно применять алгоритмы машинного обучения -- а такие работы активно ведутcя корпорацией добра например:
"...and achieve up to 7% size reduction, when compared to state of the art LLVM -Oz."

Пять стадий принятия неизбежного -- строгой статической системы типов:
- Отрицание: это ошибка компилятора, мой код правильный...
- Гнев: этот язык -- отстой...
- Торг: может быть, мне просто нужно уточнить здесь аннотации, или выполнить явный кастинг типов...
- Депрессия: мой код никогда не скомпилируется...
- Принятие: это нормально, если мой дерьмовый код никогда не будет компилироваться.

Программист "дурацкого" фул-стека (fool stack) -- это тот, кто убедил руководство попробовать Forth, а потом навечно застрял на обслуживании получившегося беспорядка )))

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

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

"Экономьте не 5 строк кода, а 50"
(с) Михаил Донской

P.S. Хотя, конечно, в реальности 80% программистов ускорить разработку действительно помогает скорее слепая печать, потому что та форма "думания", которой они следуют, не только не экономит код, а скорее немножечко вредит. Тут, да, полезнее поскорее выплеснуть своё кривое мышление в реальный кривой код, увидеть его со стороны, ну и начать бесконечно дебажить, для чего шорткаты и вот это вот всё неплохо помогают.

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

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

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

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

Ну, на демо-примере из 5 классов, действительно, может показаться, что можно теперь про классическое ООП с наследованием и полиморфизмом забыть навсегда :)

Однако когда начинаешь кодить что-то уровня Dwarf Fortress -- сюрприз! :)

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

Как правильно, на днях пост будет в основном паблике.

P.S. Но если вы про тайпклассы никогда не слышали, вообще не парьтесь; рядовой программистской работы на десятки лет вперёд хватит навалом на всех, причём тем дальше, тем её будет только больше:
78% of the web powered by PHP (1% on PHP 8)

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

Мета-антипаттерн -- это все классические паттерны проектирования, за исключением одного (выложу сегодня его разбор в ООП и ФП в Сильных Идеях), как минимум, для джуниоров, которых однако глупейшим образом любят мучить на собеседованиях по этой темке (где в 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/
ВСЕРОССИЙСКИЙ УЧЕБНЫЙ ФЕСТИВАЛЬ ПО ИСКУССТВЕННОМУ ИНТЕЛЛЕКТУ И ПРОГРАММИРОВАНИЮ
(говорят, бесплатно)