YellowClub

YellowClub

Желтый клуб — сообщество 1С программистов Наша цель — расти профессионально вместе с единомышленниками из 1С сферы Желтый клуб объединяет 1С разработчиков, 1С аналитиков и пользователей платформы 1С Предприятие. Обсуждаем фишки по 1C программированию, управлению проектами, управлению командой, автоматизированное тестирование в 1С Предприятии. Проводим регулярные стримы с интересными людьми из 1С сферы. Иногда встречаемся офлайн в разных городах.
На Пикабу
Дата рождения: 6 августа
28К рейтинг 455 подписчиков 0 подписок 377 постов 22 в горячем
Награды:
Пикабу 17 лет!
5

База знаний по чистой архитектуре⁠⁠

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

База знаний по чистой архитектуре

Конфигурацию для 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...

Показать полностью 1
1

Спор с женой⁠⁠

Спор с женой

Сегодня 11.11, вокруг скидки по этому поводу и у нас с женой случился спор. Вернее, два, но начнем с первого.

Я считаю, что все эти распродажи придуманы для женщин. Жена периодически подходит и с горящими глазами говорит: «Смотри, какие джинсы  урвала, раньше стоили в два раза дороже!». Меня это умиляет.

Мне без разницы 11.11 сегодня или обычный вторник. Нужна вещь — покупаю. Не нужна — хоть 90% скидки поставят, все равно пройду мимо.

Жена говорит, что я себя обманываю. Мужики, по ее мнению, тоже покупаются на скидки, просто не признаются и/или не замечают этого.

Может, я и правда ошибаюсь. Поэтому вопрос к вам, особенно к мужикам:

Как у вас в семье?

Рассудите нас в комментариях, обещаю показать результаты жене 👇

Показать полностью 1
1

Челлендж благодарности себе⁠⁠

Пишу из поезда.

Замечали за собой, что мы почти не хвалим себя?

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

Я решил в этот раз обернуться.

2025 год мы провели в бесконечных разъездах. Китай, Мальдивы, несколько раз Сочи, пару раз Москва. Фоном я занимался Желтым клубом и играми. Четкого понимания, чего я хочу от этих двух сфер у меня не было.

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

Что получилось:

👉 Год назад запустил курс по Архитектуре программного обеспечения. Прошло три потока. В последнем потоке акцент сделал на 1С. Участники создали конфигурацию на базе «Архитектуры бизнес компонентов» с использованием CQRS, пушей с сервера на UI, Очередей. Отличный финальный аккорд.

👉 Запустил канал по Unity. На прошлой неделе провел первый стрим. Аудитория растет.

👉 Записал больше 200 обучающих видео

👉 С января по ноябрь работал по 10 часов в день, кроме воскресенья. Это больше 2 500 часов. По сути с 2020 года я занимаюсь только одним вопросом: что такое Архитектура ПО и что такое хороший дизайн (не в смысле UI, а в смысле системного дизайна) приложений. За шесть лет скопилось под 15 000 часов.

И вот за что я благодарю себя больше всего: при всем этом я остался включенным отцом и мужем. Воскресенье у нас с женой так и осталось семейным. Работа воскресенье не съела.

Я смотрю на этот год и говорю себе спасибо. Спасибо за то, что решился пойти в сторону новой аудитории C# и Unity разработчиков. За то, что решился закрыть проект по Архитектуре на 1С, который приносит хорошие деньги. За то что решил идти дальше. За себя, как за мужа и отца.

Поэтому предлагаю челлендж.

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

Ваша очередь 👇

Показать полностью
1

Да начнутся перемены в 1С!⁠⁠

Подождем новую платформу 1С. Вот тогда и начнем писать нормальный код.

А еще лучше, подождем, пока сама фирма 1С начнет иначе проектировать типовые конфигурации. Ведь пока этого не произойдет, то какой смысл обсуждать архитектуру, границы сервисов и разделение ответственности?

В комментариях я постоянно встречаю оба этих возражения.

И здесь есть две проблемы, которые почему-то принято считать одной.

Первая — не путайте ограничения платформы с привычным способом ее использования.

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

Но платформа этого не требует.

Она предоставляет инструменты. А программист сам решает, как ими пользоваться, где размещать бизнес-логику, как организовывать взаимодействие компонентов и разделять ответственность.

Мы годами использовали платформу определенным образом. Настолько привыкли к этому подходу, что теперь воспринимаем его как техническое ограничение.

Вторая проблема — архитектура типовых конфигураций.

С этим я согласен.

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

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

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

Причем в первую очередь от этого выиграет сама фирма 1С.

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

А значит, быстрее развивать продукты.

Но у меня возникает вопрос: откуда возьмутся эти изменения, если сами разработчики будут только ждать?

Ждать новую платформу.

Ждать, пока перепишут типовые.

Ждать, пока кто-нибудь другой в команде покажет, как надо и возьмет ответственность на себя.

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

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

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

Уверен, после мини - курса «Три греха 1С разработки» вы совсем иначе посмотрите  на этот процесс. Да начнутся глобальные изменения!

Показать полностью
1

Закончил программу мини-курса «Три архитектурных греха 1С разработки»⁠⁠

Закончил программу мини-курса «Три архитектурных греха 1С разработки»

В мини-курсе демонстрирую свой подход к проектированию приложений.

Методологию проектирования я назвал «Архитектура бизнес компонент» и противопоставляю ее классическому подходу, принятому сейчас в мире 1С, — проектированию от метаданных.

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

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

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

То есть это не конфигурация с парой кнопок, а полноценные бизнес-процессы.

Разберем, что не так с привычным для 1С проектированием от существительных, метаданных, UI, печатных форм с использованием основного реквизита формы и жизненного цикла технических объектов. Покажу, чем плохи эти подходы, на что их заменить и почему это лучше. Покажу к каким конкретно ошибкам в типовых конфигурациях приводит знакомые всем подходы к проектированию.

После этого мини-курса вы посмотрите иначе на привычный подход к разработке и проектированию с использованием фреймворка «1С:Предприятие 8». Многие решения, которые сейчас кажутся естественными и единственно возможными, начнут вызывать вопросы. А главное — вы увидите, как проектировать по-другому и почему это лучше.

Показать полностью 1
1

В Microsoft работает около 230 тысяч сотрудников. Что это значит для 1Сников?⁠⁠

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

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

Прочитаем в этой новости другое.

В Microsoft работает около 230 тысяч сотрудников.

Что это для нас значит? Давайте сравним с фирмой 1С.

В фирме 1С работает около тысячи человек. Может быть, с какими-то совместными предприятиями наберется аж две тысячи. 1900 человек.

И что нам это говорит?

Это говорит о том, что Microsoft в сто раз крупнее фирмы 1С.

И когда вы в следующий раз снова скажете, что как-то не так работает конфигуратор или как-то не так работает EDT, вспомните об этом.

Вспомните, что невозможно сравнивать их с тем же VS Code, за которым стоит настолько мощная корпорация.

Фирма 1С — маленькая компания. Она просто не может все успеть. И да, она пытается развиваться и там, и там, двигается так, как двигается. Но по своим размерам она просто несоизмерима с мировыми технологическими гигантами.

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

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

Невероятные вещи совершила фирма 1С и ее основатели Сергей Нуралиев и Борис Нуралиев. Они большие красавчики, что сделали то, что сделали.

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

Фирма 1С подарила нам прекрасную платформу как фреймворк. Великолепную!

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

Показать полностью
1

Кому отдать адрес? Архитектурные страсти в 1С⁠⁠

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

В принципе, все свелось к одному вопросу: а кому принадлежит адрес доставки? Чьи это данные и кто за них отвечает?

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

👉 Проблема с синхронизацией данных между сервисами. Ровно это и происходит с Заказом клиента и сервисом Доставки. В текущем дизайне УТ 11 Адрес доставки хранится и в Заказе клиента, и в сервисе Доставки. При смене адреса доставки в Заказе клиента мы получаем рассинхрон адресов, если уже запланированы документы по Доставке.

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

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

Большинство голосов отдали за то, что адрес доставки принадлежит клиенту, то бишь контрагенту.

И Доставка должна каждый раз спрашивать у контрагента: дай свой адрес.

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

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

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

Еще был аргумент, что адрес доставки нужен не только самой Доставке, но и в других местах: на UI, в печатных формах, в том числе в УПД.

Ребята, это не аргумент. Мы не проектируем систему от печатных форм или от UI. Мы проектируем систему от данных, согласованности их изменений и бизнес-правил вокруг этих данных.

Вот это важно. А все остальное — детали реализации. Есть способы получать данные из разных сервисов, объединять их для UI и печатных форм. И ради этого совершенно не обязательно менять владельца данных или дублировать их в разных сервисах.

Дальше был хороший аргумент про законодательство и МОД — место осуществления деятельности.

Но здесь, на мой взгляд, принципиальная ошибка — отождествлять МОД и адрес доставки. Это совершенно разные понятия, разные бизнес-сущности.

Если у меня нет никакой доставки, то где же я буду хранить МОД?

Да не будешь ты его в Доставке хранить! Потому что в Доставке хранится именно адрес доставки. У него совершенно другая бизнес-суть.

Место осуществления деятельности может быть одно, а заказчик приедет и сам заберет товар. Мы вообще ничего ему доставлять не будем. Это еще раз подтверждает, что место осуществления деятельности (МОД) никак не связано с необходимостью доставки. Адрес доставки и МОД могут совпадать, а могут и не совпадать. Это разные семантические сущности.

И отсюда надо выстраивать дизайн.

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

Но самое важное — не путать адрес доставки и место осуществления деятельности. Это разные сущности, которые управляются по-разному, имеют разных владельцев, разные инварианты и бизнес-правила.

Еще обсуждали отказ от ссылок в пользу уникальных идентификаторов. Но эту тему дальше педалировать не буду. Слишком революционная идея для мира 1С. Давайте пока поживем в мире, где ссылка — это хорошо. Хотя это и не так.

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

Показать полностью
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества