Вчера жена сказала мне неприятную вещь.

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

Я поделился, что после тестов по архитектуре у меня странное ощущение 🤔

Вроде бы большинство отвечает правильно.

Видит ошибки.

Понимает, где проблема.

А потом пишут:

“У нас так никто не делает”.

“Это должна вся команда так писать”.

“В реальных проектах на это нет времени”.

“Мы всё понимаем, но работаем как работаем”.

И вот жена смотрит на меня и говорит:

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

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

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

Но применять это в работе — нет.

И тогда зачем тебе делать стрим, если в итоге это нужно трём людям?»

И я расстроился...

Первое желание — спорить и сказать, что архитектура нужна.

Что без неё 1С-проекты превращаются в ком грязи, который страшно трогать.

Что “нет времени на архитектуру” потом превращается в “нет времени на добавление новых фич”.

Гнев прошел и пришлось согласиться,  что вопрос нормальный.

Проблема в пропасти между:  “я понимаю” и “я так пишу”.

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

Отсюда вопрос👇

Вам нужен большой стрим, где я покажу, как DDD и чистая архитектура могут выглядеть в 1С мире?

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

Сделал голосовалку в боте, который сохранит ваш ответ и пригласит на тот формат, за который вы проголосуете.

Жду ваши честные ответы

Голосовать тут: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...

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

Проблема выглядит так:

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

Сразу замечу: Мартин и его «Чистая архитектура» — не единственный пример хорошего архитектурного подхода. Есть еще гексагональная архитектура, луковая архитектура. Все эти подходы говорят об одном: защищайте бизнес-логику от UI, хранилищ, фреймворков и прочей инфраструктуры.

Нашел исследования по этой теме. Они сводят эту проблему к конкретным цифрам:

— времени

— ошибкам

— стоимости сопровождения

👉 В исследовании Code Red: The Business Impact of Code Quality https://ar5iv.labs.arxiv.org/html/2203.04374 изучили 39 реальных промышленных кодовых баз и активность в 30 737 файлах. Авторы связывали качество кода с задачами из системы учета, историей изменений и временем разработки.

Выводы такие:

— код низкого качества содержит примерно в 15 раз больше дефектов;

— задачи в таком коде решаются на 124% дольше;

— худшие случаи по времени решения становятся примерно в 9 раз длиннее.

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

👉 Другая статья — Technical Debt and System Architecture https://www.hbs.edu/ris/Publication Files/2016-JSS Technical Debt_d793c712-5160-4aa9-8761-781b444cc75f.pdf . В ней исследовали две большие системы: примерно по 20 000 компонентов в каждой. Авторы смотрели на связность компонентов:

— кто от кого зависит

— где появляется центральный клубок

— насколько изменение в одном месте может потянуть изменения в других

Там хорошо видно, что дефекты распределяются по системе неравномерно.

В первой системе центральные компоненты составляли около 31% файлов, но давали почти 70% всей работы по дефектам. При этом периферийные и изолированные файлы составляли около 30% системы, но давали всего 1.1% работы по дефектам.

Во второй системе ядро составляло около 26% файлов, но давало около 62% всей работы по дефектам. В этой же системе дефекты в 5.8% периферийных файлов.

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

В этой же работе есть финансовая оценка.

В одной из систем строка кода в центральных компонентах стоила в сопровождении в 15 раз дороже, чем строка кода на периферии.

👉 Еще одно крупное исследование — работа Google Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment https://par.nsf.gov/servlets/purl/10590239

Там изучили 1252 проекта на C++ и Java и данные по 7200 разработчикам. Авторы смотрели на архитектурную сложность через несколько признаков:

— насколько изменения могут распространяться по системе

— насколько части системы развязаны между собой

— сколько есть циклов между файлами и других структурных проблем

Вывод из исследования:

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

===

Итого

Плохая архитектура приводит к тому, что:

— становится больше ошибок;

— задачи делаются дольше;

— больше времени уходит на исправления вместо новых возможностей;

— центральные компоненты становятся дорогими в сопровождении;

— изменение одного места заставляет проверять слишком много связей.

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

Вопрос в том, есть ли в системе границы, которые помогают ей развиваться

👉 Подписывайся на @YellowClub,

Приветствую всех пикабутян 1С-ников и прошу содействия в подготовке к специалисту по платформе.

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

Нашёл вот на инфостарте уже готовые решения по всем билетам, по которым вроде как можно будет даже не только сверяться, но и брать их за основы решений:
[2711959] Экзамен 1С:Специалист по платформе 8.3. ВСЕ решенные билеты экзамена (Июнь 2026)
*Решение ВСЕХ билетов + Новые Доп задачи + Полные конспекты*

Может есть тут альтруисты, которые могут взять полный набор или может у кого есть про подписка и он может на это всё потратить 10 стартмани?

Пожалуйста помогите!


P.S. Если вдруг 1С специалисты по платформе, кто уже сдал экзамен и получил сертификат, увидят сей пост, то поделитесь, что вам помогло успешно сдать экзамен и как вы сами к нему готовились.

Разработчик говорит:

«А что тут проектировать? У нас же уже есть трехзвенная архитектура: клиент, сервер 1С и база данных. Платформа все это решила за нас».

Прав ли он?

А) Да, если приложение работает в трехзвенной архитектуре, то думать о слоях и границах не нужно

Б) Нет, трехзвенная архитектура говорит только, где физически выполняется код

В) Да, архитектура всегда определяется платформой, а разработчик только раскладывает код по модулям

Г) Главное — весь важный код вынести на сервер. Тогда архитектура будет правильной

Правильный ответ выложили в своем Telegram, где можно не только «тыкнуть» на верный вариант, но и обсудить ответы с коллегами из 1С 😉

Там же в Telegram выложили еще 6 вопросов по архитектуре для 1Сников.

Переходите в канал и проверьте себя: https://t.me/+8AFMCSbhBnBlM2Iy

Давно задолжал базу знаний по чистой архитектуре.

Конфигурацию для JWT-аутентификации и авторизации через 1С отдал, а полную подборку материалов так и не собрал. Исправляюсь.

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

Что внутри:

👉 Маршрут изучения архитектуры для 1С-разработчика

В «маршруте» я разложил все по шагам:

— зачем вообще нужна архитектура;

— почему use case важнее формы;

— что такое доменная модель;

— зачем нужны диаграммы взаимодействия;

— как думать про ответственности и зависимости;

— почему функции с побочными эффектами ухудшают код;

— где появляются границы и слои;

— зачем нужны тесты;

— как работать с легаси.

👉 Видео по архитектуре

Четыре стрима, которые лучше смотреть по порядку:

— Почему код типовых так сложно понимать

— Интерфейсы и классы в 1С

— Архитектура БСП

— Архитектурный разбор обработок Контура и Диадок для ЭДО

Если времени мало, я бы смотрел первый и третий.

Первый дает общее понимание, третий поясняет на примере БСП

👉 Кейс «от я не знаю, что такое авторизация» до конфигурации с JWT за 8 дней

Это, пожалуй, самый ценный материал в подборке.

Я почти не понимал предметную область авторизации в HTTP API: JWT, токены, подписи, сроки жизни, scopes, периметр, безопасность.

А в итоге за 8 дней с помощью ChatGPT собрал рабочую конфигурацию.

Часто слышу «дайте пример реальных задач под 1С, какие делают нейронки». Показываю полный процесс работы. И это сильно проще, чем кажется:

— как задаю вопросы;

— как наращиваю контекст;

— как фиксирую результат в ТЗ;

— как прошу смотреть на решение глазами архитектора;

— как из каши неизвестных терминов постепенно собирается нормальная архитектурная форма.

Там же оставил ТЗ по подсистеме аутентификации и авторизации HTTP API.

👉 Инструкция, как подключить и оплатить ChatGPT из России

Если вы еще не пользуетесь GPT, Claude или аналогами — это проблема.

Не нужно начинать с агентов, MCP и сложных пайплайнов.

Для начала достаточно работать в чате.

Главное — научиться разговаривать с ИИ, как с напарником, а не ждать магии от одного промпта.

Забирайте базу знаний в боте: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...