Впервые мне довелось принять онлайн участие в XXV Международной научно-практической конференции «Новые информационные технологии в образовании», проводившейся 4–5 февраля 2025 года.
Это ежегодное мероприятие, организуемая компанией «1С», направленная на обсуждение актуальных вопросов внедрения новейших технологий в образовательный процесс и обмен практическим опытом среди специалистов.
Второй день конференции был полностью посвящен студентам: их ожидала насыщенная программа с множеством интересных событий, разнообразными мероприятиями и мастер-классами.
Хочу выделить несколько выступлений, которые распределил по тематическим направлениям: использование инструмента Vanessa Automation, организация процесса разработки и новый взгляд на искусственный интеллект.
Доклады в рамках темы «Тестирование»:
Доклады в рамках темы «Процесс разработки»:
- Методология, технологии и практика разработки тиражных информационных систем на платформе «1С:Предприятие» (Арипов Никита, тимлид, разработчик. Фирма «1С»)
В рамках темы по организации процессов разработки начну с интересного и наполненного дополнительными материалами доклада Никиты Арипова, тимлида и разработчика конфигурации «1С:Бухгалтерия некоммерческих организаций», создаваемой на базе «1С:Бухгалтерии предприятия».
В своем докладе Никита постарался рассказать, как разрабатывается типовая конфигурация «1С:Бухгалтерии предприятия», с чего она вообще начинается, какие задачи ставятся перед командой, что важно, что менее важно, в какую сторону нужно двигаться.
Будет много дополнительных материалов. В принципе, на некоторых слайдах есть QR-коды. Но на текущем слайде и в конце презентации всё будет собрано вместе, чтобы не переходить с каждого слайда отдельно, а после ознакомиться сразу со всеми материалами.
Рассказ начался с типовых прикладных решений. Это конфигурации, разработанные самой фирмой «1С»: «1С:Бухгалтерия предприятия», «1С:Управление торговлей», «1С:Управление небольшой фирмой», «1С:ERP» и другие. Их число ограничено, однако существует ещё множество отраслевых решений, созданных на базе перечисленных конфигураций.
Какие задачи стоят перед типовыми решениями?
Важно, чтобы они были универсальны, легко адаптируемы к потребностям заказчика, имели стандартизацию кода, масштабируемость и простоту обновлений и поддержки. Далее каждый пункт будет раскрыт отдельно — что именно под ним понимается и почему это важно.
Универсальность
Если взять, скажем, «1С:Бухгалтерия предприятия», то в России огромное количество организаций, и все они очень разные — у каждой своё направление деятельности. Сделать продукт одинаково удобным для всех почти невозможно. Здесь вспоминается известная книга по консалтингу «Закон малинового варенья»: «Чем шире мазать, тем тоньше слой». Можно создать решение сразу для всех, но оно окажется недостаточно глубоким. Коллеги выбирают другой подход: какие-то вещи делаются подробно и детально, другие оставляются поверхностными, оставляя возможность партнерам при внедрении адаптировать программу под конкретную компанию. Важно также обеспечить максимальную гибкость системы: кому-то, например, не нужна функция производства — её можно отключить одним кликом. А кто-то хочет использовать какую-либо специфичную опцию вроде комиссии — она должна легко включаться.
Адаптируемость
Помимо того, что сама программа должна работать хорошо, уметь многое, она ещё должна адаптироваться и интегрироваться с современными различными инструментами — начиная от CRM-систем и заканчивая прочими платформами BI-аналитики. Здесь, кроме инструментов, предоставляемых самой платформой («EnterpriseData»), коллеги сами в конфигурациях предусматривают разные точки интеграции. Например, была сделана специальная интеграция для CRM, позволяющая любой подобной системе обмениваться данными с «1С:Бухгалтерия предприятия». И в данном примере как раз стоит рассказать про адаптируемость. Всё чаще происходит разделение на аналитиков и разработчиков. Считается, что аналитики — это специалисты, отлично понимающие устройство программы, а разработчики занимаются непосредственно программированием. Часто получается так, что возможностями программы лучше владеют аналитики, тогда как разработчики знают их меньше. Коллеги стремятся совместить обе роли. Например, в отделе разработки бухгалтерских программ нет отдельных аналитиков — разработчики универсальны: сами анализируют решения, разрабатывают их и поддерживают впоследствии.
Стандартизация кода
У всех конфигураций открытая кодовая база, то есть любой человек может посмотреть код, увидеть, как он написан, что в нём содержится. Плюс используется библиотечный подход. Это как раз про библиотеку стандартных подсистем. Зная её, вы фактически освоите половину всех существующих конфигураций фирмы «1С»: ведь код там примерно одинаков. Библиотека подключаемого оборудования избавляет от необходимости в каждой отдельной конфигурации изобретать способ интеграции со сканерами, считывателями штрих-кодов, эквайринговыми устройствами. Всё это пишется единожды, внедряется сразу во все конфигурации и применяется повсеместно. Освоив однажды эту систему, вы сможете легко ориентироваться и эффективно применять её дальше. И система стандартов и методик разработки.
Для своей команды, потому что много разных систем уже встроено в конфигурацию «1С:Бухгалтерия предприятия», были придуманы специальные подсказки. Чтобы при добавлении нового документа или какого-то нового объекта не вспоминать, где его нужно проставить, коллеги пользуются составленными чек-листами. Например, если создаётся новый документ, сразу видно, куда его добавить и какой код ему нужно строить. Можно самим ознакомиться, как всё устроено.
Плюс для стандартизации кода придерживаются следующего правила: разработчиков много, кто пишет конфигурацию «1С:Бухгалтерия предприятия», но должно создаваться впечатление, будто её создал один человек. То есть всё должно быть примерно понятно, единообразно организовано, поскольку необходимо думать о тех, кому предстоит потом этот код сопровождать. Ведь обычно программист стремится сам разобраться во всей конфигурации и понять внутреннее устройство системы. Если в одной части кода будет написано по одному, в другом по другому — переключаться между ними будет трудно. Поэтому дополнительно тратятся силы, приводя весь код к единому стилю.
Масштабируемость
Все конфигурации и организации разные, поэтому бывает одно рабочее место, а бывает тысяча пользователей. Например, огромные внедрения в «КамАЗ», «Трансмашхолдинг» и так далее.
И здесь есть специальные лайфхаки, подготовленные описания с решением большинства возникающих проблем. Например, оптимизация запросов. Если система работает медленно, то, скорее всего, в 80% случаев причина указана тут и подробно расписаны шаги исправления. Так что тратить время на попытки самостоятельного разбора уже не придётся — ознакомившись с материалом, в 80% случаев будет понятно почему возникли какие-то проблемы.
Простота обновлений
Здесь рассматривается простота обновлений с разных сторон. Отдельно для партнёров, которые обновляют конфигурацию на новую. Отдельно для пользователей, которым тоже нужно, получив новую версию, её легко обновить. Поэтому сейчас уже есть обновления прямо из режима предприятия.
Для партнёров используется конфигурация поставщика. Это даже запатентованная фирмой «1С» технология. Сейчас вот появилась EDT плюс Git — ещё одно удобное средство для обновлений. Чтобы не ломать обновления, партнёры обычно используют расширения. Знать, как работают расширения, для чего они применяются и как с ними взаимодействовать, очень важно.
Также и для пользователей обновление должно быть очень простым. Им не нужно заморачиваться с переходом. Поэтому, когда реализовывалось обновление в «1С:Бухгалтерии предприятия» с версии 2.0 до 3.0, коллеги постарались организовать этот процесс так, чтобы он выглядел просто как обычное обновление, без каких-либо сложных переносов данных.
Какая методология используется?
Методологии разработки бывают разные: традиционные (Waterfall, Метод критической цепи и прочие) и гибкие. Нет правильного и единственно верного варианта. Выбирайте подходящий именно вам вариант, тот, который нравится. Коллеги сами попробовали несколько подходов и теперь остановились на гибких методологиях.
Сейчас используется «Канбан». Как данная методология применяется рассказывал руководитель группы Олег Фогель в своем докладе «Гибкая разработка 1С:Бухгалтерии»: как к нему пришли, какие задачи ставили, почему это важно и как работает.
Основа «Канбан» — это визуальная доска. Раньше у коллег была физическая доска прямо в офисе, куда даже экскурсии водили — все приходили посмотреть. Теперь команда гибридная: половина работает удалённо, другая половина — в офисе. Используется онлайн-доска. Во время утреннего созвона собирается вся команда, открывается доска и анализируется, как движется каждая задача.
Почему это полезно и важно? Потому что позволяет видеть непрерывность всего рабочего потока. Конфигурация «1С:Бухгалтерии предприятия» постоянно требует решения новых задач: изменения законодательства, запросы пользователей, требования партнёров. Уже много лет, вероятно около 20–30, задачи поступают непрерывно, одна за другой. Чтобы контролировать весь процесс и вовремя реагировать на проблемы, важно именно визуально следить за движением каждой задачи. Иначе легко упустить момент, когда возникнет задержка, и тогда вся система рискует встать.
Кроме того, применяется принцип «вытягивания». Обычно принято рассматривать процессы слева направо, но коллегам важнее быстро доводить каждую задачу до релиза, потому на задачи смотрится справа налево. То есть, когда разработчик свободен, он не берёт новую задачу на анализ, а помогает коллегам-тестировщикам или проверяет чужой код, ускоряя продвижение задачи ближе к выпуску релиза.
В таком постоянном процессе в отделе примерно 350 задач выпускается за год. То есть фактически ежедневно, выходит какая-нибудь одна задача. Это с учётом анализа, разработки, проверки кода, тестирования, автоматизированного тестирования и выпуска релиза. Помимо этого регулярно исправляем ошибки. И всё это надо успеть разместить в каждый релиз. Коллеги стараются выпускать релизы каждые две недели. Стремятся сделать так, чтобы всё, что успевает попасть в конкретный релиз, выходило именно там. Что не успели включить — переносится на следующий релиз. Задачи не копятся, не вытесняются одну другой, а спокойно продвигаемся вперёд.
Технологии разработки
Здесь есть несколько методологических материалов. Отдельно про технологию разветвлённой разработки конфигураций. Это когда используется несколько хранилищ для разработки. Когда применяется EDT и гибридная разработка — EDT плюс хранилище («1С:Гитконвертер»).
Подробнее про это не рассказывалось, просто была показана схема для привлечения внимания — разбираться в ней необязательно. Подробности в видеозаписи, там рассказано, как коллеги к этому пришли, как она работает, что обозначает.
Что выбрать? В чём разрабатывать? В конфигураторе или в EDT?
Коллеги разрабатывают и там, и там. Конкретного предпочтения нет. Каждая команда сама решает, в каком инструменте ей удобнее работать. Сегодня многие разработчики используют также VS Code — там тоже доступен запуск 1С прямо из среды разработки. Выбор остаётся за командой, ведь конечный результат всё равно одинаков: код собирается идентично вне зависимости от инструмента. Однако сейчас большинство команд постепенно переходят в EDT, поскольку эта среда активно развивается, добавляет новые функции вроде поддержки искусственного интеллекта и другие перспективные технологии.
Code-review
Помимо разработки проверяется и сам код — проводится код-ревью. Любой код, выполняемый нами, обязательно просматривается ещё кем-то. Это крайне важная практика. Шутливо говоря, код-ревью объясняет, почему зарплата тимлида выше зарплаты разработчика: достаточно указать пропущенную точку с запятой. Коллеги проверяют весь выпускаемый код программы, включая тесты и обработки, стараясь исключить возможные ошибки.
Тестирование
Отдельно рассказ был посвящен процессу тестирования. У коллег есть автоматизированное тестирование. Для этого используется конфигурация «1С:Сценарное тестирование». Она позволяет запускать автоматические тесты, чтобы избежать ручной проверки всех моментов, то есть для каждой конфигурации автоматически проходят все сценарии тестирования при помощи роботов. По сути, выполнение всего набора сценариев человеком заняло бы около 30 месяцев, а так оно осуществляется ночью всего за восемь часов. Дополнительно коллеги ведут курсы в МФТИ и ВШЭ по управлению качеством бизнес-приложений, где делятся опытом и подходами.
CI/CD
Именно потому, что нужно выстраивать все эти процессы — сборку, проверку и прочее, — у коллег используется конвейер сборки. Каждую ночь запускается сборка конфигурации, формируется полный дистрибутив со всеми обновлениями и изменениями. Затем на нём прогоняются всевозможные тесты: автотесты, статический анализ кода и другие.
Утром следующего дня появляется таблица, показывающая текущее состояние релизов. Каждый день собираются одновременно два-три релиза разных версий, хотя это вовсе не значит, что все они выйдут в продакшен. Формируется обобщенная информация о том, в каком они находятся состоянии. Если всё хорошо — как в третьем зелёном столбце на слайде — релиз можно передать. Но передавать его или нет — отдельный вопрос: содержит ли он важные изменения, нужные пользователям? Столбцы таблицы соответствуют выпускаемым релизам, строки — выполняющимся проверкам. Система легко расширяется: когда появляются новые проверки, мы их добавляем и убеждаемся, что процесс идёт гладко.
Стек технологий
И напоследок Никита поделился сборной статьёй про стек технологий для 1С. В ней собрано всё, что касается непосредственно самой системы, её кода, плагинов для «VS Code» и 1«1С:Enterprise Development Tools» и прочего. Если станет интересно познакомиться с этими материалами подробнее — доступна ссылка.
При возникновении вопросов, можно написать Никите на почту.
На этом всё. Спасибо большое за внимание!