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