Желтый клуб

Пятничный мем 🟡 Жёлтый клуб в MAX

Спасибо за вопросы в боте! Забрал их в работу на подготовку 🤝 Больше 700 человек проголосовали за участие в стриме по теме DDD. Вот это вы поднажали 🔥 Я не ожидал такого количества. Думал, посмотрим на реакцию и уже решим, насколько тема вам нужна. Теперь все ясно без дополнительных исследований. Теперь груз ответственности стал еще больше. Обещаю, что стрим будет годным. Разберем все на конкретном примере в 1С: посмотрим конфигурацию, код и то, как можно отделять бизнес-логику от объектов системы. Вдвойне приятно, что голосованием вы не ограничились. На просьбу прислать свои вопросы и темы вы написали около 60 ответов. Причем не просто «расскажите про архитектуру», а вполне конкретные боли: 🟡 как внедрять нормальную архитектуру в существующую кашу 🟡 что делать с типовыми конфигурациями 🟡 как делить систему на слои 🟡отделять логику от интерфейса 🟡защищать архитектурные решения перед коллегами и не превращать очередную доработку в новый технический долг Часть вопросов затронем на стриме. А остальных хватит еще на несколько эфиров вперед. Спасибо, что так включились. Это очень мотивирует готовить больше нормального и полезного контента. Встречаемся 23 июля в 19:00 МСК в ютубе, рутубе, вк. Если еще не зарегистрировались и не хотите пропустить напоминание о стриме — присоединяйтесь по ссылке

Пятничный мем 🟡 Жёлтый клуб в MAX

Стриму по DDD быть. Вижу, что интерес есть, поэтому ставим дату: Четверг 23 июля в 19:00 МСК Тема: «DDD и слои в 1С-разработке с примером конфигурации, кодом и разбором, как это применять в 1С мире» Пока по количеству регистраций мы вмещаемся в закрытый Zoom. Если так и останется, то сделаем камерный формат без записи: спокойно все обсудим и пообсуждаем голосом. Если доберем 200+ регистраций, тогда проведем большой стрим с записью. На стриме разберем: 🟡почему думать от UI или метаданных — путь к комку грязи в архитектуре; 🟡что такое «проектирование архитектуры» на самом деле; 🟡как выделять слои и зачем они нужны; 🟡как проектировать домен по DDD; 🟡зачем вообще нужен DDD, если у нас есть справочники, документы, регистры и типовые механизмы; Пока с активностью в канале приторможу. Подготовка сложная, потому что тема большая и хочется показать не теорию ради теории, а реальный практический пример. Если хотите попасть на стрим — регистрируйтесь в боте. По количеству регистраций финально выберем формат: закрытый Zoom без записи или большой стрим с записью. Регистрируйтесь тут

Вчера жена сказала мне неприятную вещь. Мы обсуждали планы на ближайшие две недели, и оказалось, что много времени уйдёт на подготовку к стриму по DDD в 1С. Я хочу не просто выйти и поговорить про DDD и хорошую архитектуру, а доработать типовую конфигурацию и показать, как DDD и слои могут выглядеть в 1С. Показать, какие задачи можно с помощью такого подхода решать. Я поделился, что после тестов по архитектуре у меня странное ощущение 🤔 Вроде бы большинство отвечает правильно. Видит ошибки. Понимает, где проблема. А потом пишут: “У нас так никто не делает”. “Это должна вся команда так писать”. “В реальных проектах на это нет времени”. “Мы всё понимаем, но работаем как работаем”. И вот жена смотрит на меня и говорит: «Жень, тебе не кажется, что эта архитектура никому не нужна, кроме тебя? Ты сейчас две недели будешь носиться с этой конфигурацией, готовить стрим, разбирать DDD и чистую архитектуру. А может, это мало кому нужно? Может, лучше уехать в отпуск, лечь у бассейна и нормально отдохнуть? Потому что людям, кажется, интересно пообсуждать архитектуру, поставить правильный ответ в тесте, написать умный комментарий. Но применять это в работе — нет. И тогда зачем тебе делать стрим, если в итоге это нужно трём людям?» И я расстроился... Первое желание — спорить и сказать, что архитектура нужна. Что без неё 1С-проекты превращаются в ком грязи, который страшно трогать. Что “нет времени на архитектуру” потом превращается в “нет времени на добавление новых фич”. Гнев прошел и пришлось согласиться, что вопрос нормальный. Проблема в пропасти между: “я понимаю” и “я так пишу”. И мне интересно, насколько эта пропасть вообще кому-то мешает. Может, я правда смотрю на это через свою профессиональную деформацию. А может, рынку достаточно знать, как правильно, но продолжать писать как принято. Отсюда вопрос👇 Вам нужен большой стрим, где я покажу, как DDD и чистая архитектура могут выглядеть в 1С мире? Или это тема для закрытого разбора в ZOOM на несколько человек, которым реально надо так писать, а не просто послушать? Сделал голосовалку в боте, который сохранит ваш ответ и пригласит на тот формат, за который вы проголосуете. Жду ваши честные ответы Голосовать тут Голосовать тут

Стас требует доказательства, что хорошая архитектура помогает решить проблему превращения кода приложения в большой ком грязи. Проблема выглядит так: кодовую базу все еще можно запускать, но развивать ее становится все тяжелее. Разработчики все больше времени тратят на исправление ошибок, согласование изменений и понимание старого кода, а не на развитие функциональности. Сразу замечу: Мартин и его «Чистая архитектура» — не единственный пример хорошего архитектурного подхода. Есть еще гексагональная архитектура, луковая архитектура. Все эти подходы говорят об одном: защищайте бизнес-логику от UI, хранилищ, фреймворков и прочей инфраструктуры. Нашел исследования по этой теме. Они сводят эту проблему к конкретным цифрам: — времени — ошибкам — стоимости сопровождения 🟡В исследовании Code Red: The Business Impact of Code Quality изучили 39 реальных промышленных кодовых баз и активность в 30 737 файлах. Авторы связывали качество кода с задачами из системы учета, историей изменений и временем разработки. Выводы такие: — код низкого качества содержит примерно в 15 раз больше дефектов; — задачи в таком коде решаются на 124% дольше; — худшие случаи по времени решения становятся примерно в 9 раз длиннее. Плохая архитектура — это больше ошибок, больше времени на задачи и хуже предсказуемость разработки. При этом проблема не просто в количестве строк. Большой файл сам по себе еще не проблема. Беда начинается, когда код трудно понимать и менять: обязанности перемешаны, методы и классы разрастаются, а одно изменение требует держать в голове слишком много неявных связей. 🟡Другая статья — Technical Debt and System Architecture. В ней исследовали две большие системы: примерно по 20 000 компонентов в каждой. Авторы смотрели на связность компонентов: — кто от кого зависит — где появляется центральный клубок — насколько изменение в одном месте может потянуть изменения в других Там хорошо видно, что дефекты распределяются по системе неравномерно. В первой системе центральные компоненты составляли около 31% файлов, но давали почти 70% всей работы по дефектам. При этом периферийные и изолированные файлы составляли около 30% системы, но давали всего 1.1% работы по дефектам. Во второй системе ядро составляло около 26% файлов, но давало около 62% всей работы по дефектам. В этой же системе дефекты в 5.8% периферийных файлов. То есть проблема в том, что внутри появляется связанный центр, через который проходит слишком много изменений. Исправляешь одно место — задеваешь другое. Добавляешь новую возможность — неожиданно ломаешь старое поведение. В этой же работе есть финансовая оценка. В одной из систем строка кода в центральных компонентах стоила в сопровождении в 15 раз дороже, чем строка кода на периферии. 🟡Еще одно крупное исследование — работа Google Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment. Там изучили 1252 проекта на C++ и Java и данные по 7200 разработчикам. Авторы смотрели на архитектурную сложность через несколько признаков: — насколько изменения могут распространяться по системе — насколько части системы развязаны между собой — сколько есть циклов между файлами и других структурных проблем Вывод из исследования: чем больше связность, чем больше циклов между файлами и проблемного наследования, тем меньшая доля работы уходит на новые возможности и тем большая — на исправление ошибок. === Итого Плохая архитектура приводит к тому, что: — становится больше ошибок; — задачи делаются дольше; — больше времени уходит на исправления вместо новых возможностей; — центральные компоненты становятся дорогими в сопровождении; — изменение одного места заставляет проверять слишком много связей. Хорошая архитектура решает обратную задачу: уменьшает связность, ограничивает распространение изменений и не дает бизнес-логике утонуть в UI, базе данных и инфраструктуре. Вопрос в том, есть ли в системе границы, которые помогают ей развиваться 🟡Подписывайся на канал Желтого клуба

Слово Архитектура я долго не понимал и думал, что это что-то сложное. Определения типа: «Архитектура — это высший уровень абстракции моделей», понимания не добавляли, а только вводили в уныние. Архитектура — это очень просто. Мне больше всего нравится определение Архитектуры Роберта Мартина в книге «Чистая архитектура»: Архитектура программной системы — это форма, которая придается системе ее создателями. Эта форма образуется делением системы на компоненты, их организацией и определением способов взаимодействий между ними. Цель формы — упростить разработку, развертывание и сопровождение программной системы, содержащейся в ней. Главная стратегия такого упрощения в том, чтобы как можно дольше иметь как можно больше вариантов. Чтобы иметь как можно больше вариантов, необходимо изолировать доменную модель и бизнес-логику от инфраструктуры, UI

Пятничный мем 🟡 Жёлтый клуб в MAX

По результатам квиза стало понятно, что в Желтом клубе исключительно отличники по архитектуре. 90% правильных ответов. И это, конечно, радует. Но у меня тогда возникает следующий вопрос. Если мы все это понимаем, то почему продолжаем писать код так, как будто не понимаем? 🟩Про трехзвенную архитектуру пока опустим. Надеюсь, здесь всем понятно, что клиент, сервер 1С и база данных — это не архитектура приложения, а вариант развертывания. 🟩Про форму тоже пока опустим. Думаю, все плюс-минус согласны, что форма не должна быть местом бизнес-логики. Форма должна принять ввод, показать результат и дернуть что-то дальше. Максимум — какие-то проверки для удобства пользователя. А дальше начинаются вопросы. 🔴Если вы понимаете, что форма не должна владеть бизнес-логикой, то почему продолжаете пробрасывать основной реквизит формы куда-то вглубь? Почему Объект формы становится единым контейнером для всего? Он и на форме. Он и вход в бизнес-логику. Он и выход из бизнес-логики. Он и состояние UI. Он и объект записи. Он и временный контейнер изменений. Почему так? Почему сценарий не получает нормальные входные данные и не возвращает нормальный результат? 🔴Если вы понимаете, что бизнес-действие не должно собираться из обработчиков, то почему продолжаете так писать? Почему изначально мышление идет не от сценария, а от событий платформы? «А давайте здесь в ПередЗаписью добавим». «А тут в ПриЗаписи проверим». «А это в ОбработкаПроведения положим». В итоге нет одного места, где можно прочитать сценарий целиком. Есть расследование по обработчикам. 🔴Если вы понимаете, что плохо проектировать от форм или метаданных, то почему только эти подходы и используются? 🔴Если проверка заполнения, настройки на форме и ОбработкаПроверкиЗаполнения — это не полноценная защита бизнес-правил, то где вы тогда защищаете инварианты? Что для вас вообще инварианты? Как вы достигаете того, что документ или справочник записывается в согласованном состоянии? Как вы решаете что это валидация пользовательского ввода, а это уже важный бизнес-инвариант? 🔴Про циклические зависимости. Циклические зависимости — классика типовых конфигураций. И вообще классика мира 1С. Модуль проведения вызывает взаиморасчеты. Взаиморасчеты вызывают модуль проведения. Один общий модуль вызывает второй. Второй вызывает первый. И все как будто нормально. Но весь остальной мир программирования говорит: циклические зависимости — это очень плохой сигнал. Это значит, что границы ответственности не проведены. Если в программировании в целом циклические зависимости считаются проблемой, то почему в 1С это норма? Почему мы к этому привыкли? Почему нас это не смущает? В общем, квиз получился интересный. Почти все знают правильные ответы. Но .... почему мы так не пишем?

Что это означает с точки зрения архитектуры?