По поводу того как архитектура мешает делать неправильные вещи

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

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

Изоляция, грануляция, проведение границ, разделение ответственности - основные архитектурные инструменты на уровне системы и приложения.

Типы, принципы и паттерны - это инструменты архитектуры на уровне кода.

Вопрос: Можно ли в domain слой добавлять классы со специфичными ORM атрибутами если ORM плохо поддерживает генерацию POCO классов? Надо ли воевать с этим?

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

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

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

Хотя погодите, а че это за хер?

Интересно, этот человек когда-нибудь от меня отъебется? Как объяснить, что мне совершенно параллельно, что он думает?

Как типы помогают программировать

Заметил, что после того как программист переходит на TypeScript, после чистого JavaScript, то через некоторое время, он все меньше смотрит в браузер и все больше доверяет парсеру TS. Цикл работы сокращается и разработка идет быстрее.

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

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

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

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

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

По поводу набора в NarisApp
Анализ заявок и приглашение к участию будет ближе к концу недели, пока собираю все обращения. Набор будет примерно 20 человек, пока заявок немного, поэтому пока попадают все.

Субботнего стрима не будет

Завтра стрима не будет. Отдыхаем, набираемся сил.

Набор в NarisApp в IV набор завершен

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

Спасибо всем кто откликнулся.

HATEOAS (Hypermedia as the Engine of Application State)

Недавно в чате обсуждалось соответствие современных REST API требованию единообразия интерфейсов в REST, в частности речь шла о HATEOAS.

С учетом того, что REST API почти всегда делают на базе веб-решений, это требования выполняется по дефолту. Тут надо вспомнить, что REST появился как архитектурный стиль в то время, когда про WEB 2.0 еще толком никто не знал.

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

На самом деле в мире где еще не было WEB 2.0 HATEOAS означал лишь то, что REST приложение должно работать не с каким-то специфичным клиентом, который реализует свой протокол, а с любым приложением которое умеет работать с гипермедиа, т.е. по сути любые веб-клиенты.

Отсюда, если ваш REST API может быть доступен по HTTP через браузер, консольный клиент или как-угодно клиентом понимающим HTTP, то он дефакто HATEOAS.

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

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

Субботний стрим 28.10 10:00

Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:

- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают

В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.

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

Завтра поднимаю цены на доступ к ресурсам SOER.PRO.
Для всех у кого есть действующая подписка ничего не меняется, подписка будет пролонгироваться на тех условиях, которые были в момент приобретения подписки.

Если давно думали взять подписку в клуб SOER.PRO, то рекомендую сделать это сегодня по старым ценам (STREAM по 350 рублей в месяц), завтра будет дороже.

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

Оценка сложности кода

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

В итоге проще считать строчки, чем искать другие сложные метрики.

Для отчётности бывает "красиво" показать умные оценки кода, но для практики смысла мало.

Можно еще вспомнить про покрытие кода тестами - это тоже сомнительная метрика. Не совсем бесполезная, но сильно большой пользы тоже нет.

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

Оценки обычно нужны для того чтобы прикинуть размеры команд и объёмы сопровождения, это в свою очередь помогает рассчитать стоимость владения. Для самих разрабов пользы особо нет, но бизнесу надо знать сколько денег у него уходит и почему.

Подписчик с ником Das.Kleine.Krokodil сделал подробные таймкоды к последнему стриму.
От души спасибо! Это прям то на что не хватает ни времени, ни сил.

Был ли опыт применения DSL, и если да, то был ли такой, который явно помог(«с ним лучше, чем без него») и по каким критериям/метрикам мерил?

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

Во-первых, потому что надо писать меньше кода.

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


Стоит отметить, что в мире более 7000 языков, большая часть из которых - DSL.


Единственный серьёзный минус разработки своего DSL - это затраты (как цена, так и сроки).

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

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

Странный наброс, если говорить про Россию, то АйТи у нас развито на уровне выше среднего по миру, по факту одна из лидирующих позиций. Начиная от банкинга, заканчивая уровнем информатизации государства.
Опыт показывает, что ТЗ офигенно работает.

Мне тут сбросили ссылку на мое видео 6ти летней давности про то что должен знать архитектор, очень актуальный видос, с подробным ответом. Посмотрел и порадовался за самого себя.
Отметил, что формат канала сильно изменился за эти шесть лет, стал более развлекательным, раньше я пытался больше концентрироваться на сути, сейчас на форме.
https://youtu.be/Qt1IxhoQ2dw?si=jO-QA3NCVWM9nGB1

Откуда можно черпать знания по архитектуре?

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

Классификация

1. Базовые знания (или "база") - Теория программирования, Информатика, Языки программирования, устройство ОС, системы хранения данных и т.д.
2. Технические навыки (или "опыт") - это углубление знаний и реальный опыт работы, автоматизация своих навыков, развитие "ощущения" языка программирования, когда вы понимаете где "хорошо", "где плохо" и т.д.
3. Специализированные знания (или "специализация") - это когда вы находите конкретную область, которая вам интересна и получаете знания, которые релевантны только в этой области, они могут быть как технические, так и бизнесовые
4. Архитектурная карьера - карьерный переход из разработчика в Архитекторы, приоритет на проектирование и построение системы в целом, а не на детали.

Абстрактные советы

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

ВУЗ не отменяет дополнительно самообразование через литературу.

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

Построение базы занимает от 3-5 лет.

2. Опыт

Теория без практики мертва. Поэтому важно продумать свой карьерный план - найти перспективные компании, которые интересны, понять как требования для трудоустройства, с учетом этого расставить приоритеты изучения по "Базе". Соответственно иметь примерный план развития, на 1-2 года, в процессе которых пытаться искать работу.

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

Стандартная карьерная лестница джун - мидл - сеньер, где каждый уровень 1-2 года, т.е. при хорошей Базе, и нормальной работе можно за 5 лет дорасти до сеньера.

3. Специализация

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

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

4. Архитектура

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

Конкретика

- Для базовой подготовки хороши курсы CS50, SICP, книги Таненбаума, Маконнела, Роберта Мартина.
- Для развития опыта - МЯСО (МейлРу, Яндекс, Сбер, Озон), системные интеграторы (ИБС, Фактор-ТС и другие, где есть неплохой карьерный рост), государственный сектор (например, ГОСУСЛУГИ), либо компании с историей 5-10 лет и прозрачной карьерной составляющей
- Для быстрого старта, можно рассмотреть всякие буткемпы аля Школа 21
- Для изучения архитектуры см список книг ниже.

Архитектура ПО (первые шаги)
Clean Architecture (Robert C. Martin)
Domain Driven Design (Vaughn Vernon)
Architecting for Scale (Lee Atchison)
Software system architecture (Nick Rozanski, Eoin Woods)
Применение UML 2.0 и шаблонов проектирования (Крэг Ларман)
Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith (Sam Newman)
Software Architecture in practice (Len Bass, Paul Clements, Rick Kazman)
Software Architect's Handbook: Become a successful software architect by implementing effective architecture concepts (Joseph Ingeno)