Тут в последнее время много кулсторей про то, что высшее образование обосраться как нужно, а все айтишнички без него попуски. Такое чувство как будто я один учился в ВУЗе: некомпетентные преподаватели, которые тебя ненавидят; всратая обучающая программа, которая ставит инженеру культурологию; лизание жопы как самый надёжный способ сдать экзамен.

Я не отрицаю, что от ВУЗа можно получить полезности в виде выгодных связей или определённой информации. Так ведь можно и не получить. И вообще бумажечка-диплом хороша, можно перед еблом барина ей помахать и выбить плюшки. ВУЗ - для айтишнека это полезно, но далеко не необходимо. Особенно если учесть, что большинство выпускников - огрызки. Только вертлявое, гениальное, успешное, хитрожопое и амбициозное меньшинство становятся айти-сверхлюдьми, техножрецами, полулюдьми-полукомпиляторами. И неужели вы думаете, что это меньшинство без ВУЗа были бы вафельниками? Не путайте причину и следствие.

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

Нет. Модуль и агрегат - это разные вещи. Задача модуля упаковать взаимодействующие элементы системы для уменьшения зацепления (low coupling). В модуле, как правило, содержится один агрегат, но может быть и несколько. Кроме агрегата модуль может содержать и другие элементы.
Подбронее - https://culttt.com/2014/12/10/modules-domain-driven-design#what-are-modules

Маслятки попытались меня взять на понт что-ж кратко о том, что выучил исключительно благодаря ВУЗу:
- сетевой стек и устройство ЛВС
- теорию построения компиляторов (например, всякие рекурсивные спуски, которые я потом использовал, чтобы парсить логи для сбора информации по системам)
- основы криптографии (например, именно там мне объяснили, что такое абсолютно устойчивые шифры, и что сам по себе XOR - не является методом устойчивого шифрования, нужны доп. условия, которые многие почему-то забывают);
- устройство ОС (я перешел на Линукс, как раз в ВУЗе), процессы, потоки и т.д.
- все что я знаю о нейронных сетях я выучил как раз в ВУЗе (я на дипломе писал свою первую нейронку, обучающуюся по методу обратного распространения ошибки, что такое антиградиент, например, я узнал тогда же. Учился я одного из лучших преподов по ИИ - Е.М, Миркеса и то что я попал к нему на диплом - это огромная удача)
- тер. вер (прям очень рад, что в ВУЗе меня заставили учить эту муть, потом много где использовал по работе, как минимум понимал основы - что такое дисперсия, мат. ожидание и т.д.)
- СУБД (всякие "первая, вторая нормальные формы", реляционные модели данных и т.д.)

До ВУЗа я был обычным масленком, в ВУЗе из меня сделали настоящего человека. ) Душнить, кстати, тоже научили в ВУЗе. ) Выучил бы я все это без ВУЗа? Да нифига! Единицы, кто вообще будет составлять себе какую-то программу, и потом идти по ней. Это только в своих влажных фантазиях все увлеченные, целеустремленные и гениально умные. А на практике: "все с завтрашнего дня начинаю учиться".

Дима пытается втиснуться между двумя титанами мысли )

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

Но знаете что? Не получится! Проблемы современного веба системные, идущие в первую очередь от невероятной кадровой некомпетентности и "пропатчить" новой заплаткой - не выход.

Женя SOeR Сергеев (даже не будем говорить о всех регалиях, он слишком известен 🤫) в нашей студии!

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

А также: кого бы забанил Женя на Ютубе, если бы мог? Какой проект самый любимый? Что с фанатами?

Го смотреть!

https://youtu.be/aWoAmBqc2FE

Не будет никакого "самоочищения" все попытки что-то улучшить будут упираться в необходимость качественно обучить хулиард фронтендеров, а это бизнесу сильно дорого встанет, проще барахтаться с кучей херовых абстракций. ИМХО.
https://t.iss.one/t0digital/629

Такая фигня в этом стриме. Такое ощущение, что они психологическую помощь оказывают, а не о менторстве говорят.
https://m.youtube.com/watch?v=PTUbnLLwcMc

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

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

Немного про DDD и анемичные модели

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

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

В Domain Driven Design есть такое понятие как "анемичная модель", это как правило модель, которая не содержит логики и имеет только set/get методы. В данном подходе это плохо тем, что логика выносится за пределы модели и соответственно ее сложнее сопровождать, тестировать и развивать. Чем ближе связанные друг с другом вещи находятся, тем проще с ними работать.

Согласно логике DDD анемичной должна быть база данных. Целостность и логика должны быть заботой кода (с использованием транзакций), а в БД должны только хранится данные. В задачах где требования целостности укладываются в BASE это работает очень хорошо.

Но анемичная БД очень грустная штука, когда речь идет об ACID, просто потому что реализовать на уровне клиента целостность будет сложнее. Во многих бухгалтерских приложениях среднего размера, в системах отчетности и т.д. близость обработки к данным - это большой плюс. Можно сильно сэкономить и на размере команды, и выиграть в скорости работы. В больших приложениях "жирная" СУБД становится проблемой, но если задача хорошо ложиться на реляционную модель, то можно и в таком случае логику держать на уровне СУБД.

Как только мы начинаем выносить логику на СУБД, то мы автоматом множим анемичные модели в коде. Это как закон сохранения энергии, чтобы где-то прибыло, нужно чтобы где-то убыло.

Можно ли сказать, что вынос логики на уровень СУБД - это всегда зло? Нет! Во многом такой подход позволяет проще решать вопросы целостности и скорости работы. Естественно есть минусы - сложно горизонтально масштабировать, сложнее тестировать, сложнее дебажить. Но зато до определенного размера - быстрее работает, надежнее работает, меньше людей нужно для сопровождения.

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

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

#ddd #архитектура #мысли