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

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

У меня довольно большой опыт в проектной деятельности 1С и в разработке крупных проектов. Мы занимаемся IT-консалтингом, автоматизацией и разработкой собственных продуктов, в том числе продукта, который работает с маркетплейсами. Разрабатываем на платформе 1С RDV Маркет. Являемся официальным техпартнером четырех ведущих маркетплейсов России.

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

Что представляет из себя публичный интерфейс? Это система, которая работает в облачной среде RDV. Она является неким адаптером для работы с маркетплейсами. Под капотом она скрывает всю сложную логику взаимодействия с API маркетплейсов и в итоге выдает уже наш общий, унифицированный для всех API-интерфейс для работы со всеми маркетплейсами.

Сам API является отдельным продуктом и хорошо задументирован. Наше расширение – одно из возможных решений для работы с ним. Любая система, которая умеет общаться с HTTP-сервисами, может к нему подключаться и использовать.

EDT и его преимущества

Про EDT сложно сказать что-то новое, но вспомним некоторые основные вещи. Это современный IDE, и тем, кто поработал в других средах разработки, уже кое к чему привыкли – им это не покажется новым. А для тех, кто работал в конфигураторе, что-то может показаться непривычным.

Первое, это интеграция с Git. Это почти отдельная область знаний, много разных нюансов. И какая современная среда разработки без Git?

Инструменты в EDT богаче, чем в конфигураторе: это различные контекстные подсказки, больше возможностей по кодогенерации. Мощный инструмент, предельно детальный – сравнение и объединение объектов. Проверка кода фактически из коробки, это стандартный плагин от 1С.

Что еще очень удобно, предоставление единого пространства для разработки. Фактически наш продукт состоит из каких-то компонентов: это конфигурация, разные расширения, мы все это хотим видим в одной рабочей области, чтобы можно было быстро переносить объекты, сравнивать и объединять.

Если чего не хватает и хочется дополнительно добавить в среду разработки, то пожалуйста: есть стандартные плагины от 1С, появляются плагины от сообщества, есть плагины, которые идут прямо от родной среды для EDT – Eclipse. Все это можно использовать.

Проблемы и ограничения EDT

Однако есть известные проблемы. Как правило, они касаются крупных проектов – там, где у нас:

• типовые конфигурации,

• ограниченное время,

• ресурсы,

• «плавающая» команда, которая зависит от стадии проекта: мы то подключаем разработчиков на проект, то отключаем, если объем разработки уменьшается.

Все это усложняет работу с EDT.

Не хватает скорости работы, если мы используем типовую конфигурацию и начинаем переключаться между ветками, Git-проект начинает пересобираться и мы ждем, пока все отработает. Достаточно долго работают и другие инструменты, например, сравнение и объединение. Еще можно сказать, что EDT неэкономичен по отношению к вычислительным ресурсам. Если конфигурация большая, то даже речи не идет о том, что мы будем разрабатывать на каком-то общем терминале разработки. Скорее всего, это будут индивидуальные рабочие места на достаточно мощных компьютерах.

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

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

Процессы работы с EDT во всех командах так или иначе отличаются.

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

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

Когда было бы хорошо использовать EDT, и все его «фишечки» заработали бы? Это, наверное, небольшая конфигурация и стабильная команда, когда нет такого, что мы подключаем и отключаем разработчиков.

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

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

Причины выбора EDT для нового продукта

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

Предыдущая конфигурация у нас была построена на базе «Комплексной автоматизации». Это выливалось в определенные проблемы, когда мы обновляли конфигурацию. Типовая конфигурация – большая, тяжелая, и периодически требует больших технологических окон. А процессы, связанные с работой с маркетплейсами, оперативные. Даже ночью есть активность, заказы идут постоянно, то есть это круглосуточные процессы. Технологические окна ночью – это боль.

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

Здесь в голову сразу пришло решение: давайте выделим отдельную маленькую конфигурацию, чтобы не было ничего сложного, большого, без БСП, чтобы она обновлялась максимально быстро, меньше чем за минуту. Это должно было радикально решить нашу проблему, да и всегда интересно попробовать что-то новое в работе.

Мы знали про минусы EDT, что с большими конфигурациями работает тяжело. Но если у нас маленькая конфигурация, то нас это не касается. Решили попробовать.

Еще есть «фишечки». У нас модульный продукт, он состоит из множества разных конфигураций, расширений, EDT позволяет объединить все это в одном общем окне. Меньше переключений внимания.

Опыт работы с «монорепозиторием» и переход к распределенной структуре

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

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

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

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

Значит, надо уходить от монорепозитория. Первым делом вынесли типовые конфигурации из общего репозитория.

Стало легче.

Теперь можно использовать ветки. Сразу сделали ветку dev для разработки, туда заливаем все новые фичи. И отдельно ветку release, в этой ветке мы готовим релиз, исправляем ошибки. Сразу начали использовать инструменты Git: мы разрабатываем, но в какой-то момент появляется точка, с этой точки мы начинаем собирать релиз, делаем мердж в релизную ветку, тестируем релизную конфигурацию, находим и исправляем ошибки.

Если исправляем ошибки в релизной конфигурации, обратно переносим с помощью cherry-pick. Это инструмент Git, который позволяет взять отдельный коммит из одной ветки и перенести его в другую.

Проблемы синхронизации кода и переход на форки

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

Мы разрабатываем в одной конфигурации, а потом синхронизируем эту общую кодовую базу в других расширениях. Делаем сравнение-объединение, чтобы перенести библиотеки. Обновляем в расширении библиотеку, а после этого там возникают ошибки.

Например, в расширениях недоступны определяемые типы, недоступны глобальные модули, в EDT появляются битые ссылки в подсистемах, в ролях.

То, с чем конфигуратор справлялется по умолчанию, сам как-то чистит составы метаданных объектов, метаданных, ролей., EDT переносит объекты «в лоб». И неважно, что какой-то объект не перенесся, используемый в подсистеме, в подсистеме возникет битая ссылка на этот неперенесенный объект.

Нужно было как-то это исправлять. Решили сделать инструмент, который просто пробежится по исходным файлам и все эти ошибки исправит:

• определяемые типы просто разнесет на составные части,

• лобальные модули сделает обычными, снимет соответствующую галочку,

• несуществующие объекты в подсистемах удалит

и все это сделает программно через исходники EDT.

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

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

Получилась интересная задача. Написали библиотечки, скрипты, которые работают “как EDT”: парсят исходные файлы, представляют их как объекты. Мы настраиваем, какие объекты нужно перенести, с каким составом, какими реквизитами, и все работает. Произошел своеобразный реверс-инжиниринг исходников EDT.

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

Было ощущение, что должно быть какое-то простое решение. Надо посмотреть под другим углом, изменить систему координат.

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

После этого обновление расширений для типовых конфигураций из базового расширения фактически выполняется по одной кнопке. В GitLab есть кнопка «Обновить репозиторий из форка», нажимаем, и все изменения автоматически переносятся из базового репозитория.

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

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

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

Для расширений такой возможности нет: нельзя сделать поставку на основе расширения. Но с этой задачей прекрасно справляются EDT+Git и форки: делаем расширение как типовое, дорабатываем, потом через форк средствами Git обновляем.

Можно заметить, что “монорепозиторий” оказался для нас плохим решением. Собрать все в одну кучу в один репозиторий лишило возможности использовать стандартный функционал ветвления в Git для синхронизации кодовой базы. Оказалось разбивать репозитории по программным решениям с учетом иерархии предок-потомок и функциональности.

Если есть желание разрабатывать в EDT, и есть маленькая конфигурация, то это прекрасное сочетание, чтобы использовать все возможности EDT.

Архитектурные решения и слои абстракции

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

Мы для себя четко разделяем слои абстракции нашего решения:

• Есть типовая конфигурация.

• Есть наше расширение с объектной моделью, которая совершенно не зависит от типовых объектов.

• И есть выделенная точка соприкосновения. Это переопределяемый программный интерфейс, всем разработчикам знакомая вещь по типовым конфигурациям. Только в этой точке мы создаем соприкосновение нашей объектной модели и типовой конфигурации.

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

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

Мы не трогаем БСП, потому что в разных типовых конфигурациях могут быть разные версии БСП, иначе сразу попадаем на то, что может отличаться программный интерфейс, об этом тоже нужно будет заботиться, проверять, а это усложняет работу. За счет этого мы достигаем стабильности и понятности поведения нашего решения. Та часть, которая переопределяема, уже разрабатывается в форках для типовых конфигураций.

Полезные фичи EDT, реально помогающие в разработке

Немного про интересные штуки и полезности EDT, которые нам действительно пригодились в работе, и мы считаем, что это здорово – ради этого можно использовать EDT.

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

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

Наличие интеграции с Git в EDT позволяет нам использовать GitLab с merge requests. Мы используем это для выполнения ревью. Разработчик создает для себя отдельную ветку, разрабатывает в этой ветке, формирует merge requests, а технический архитектор или ведущий разработчик с помощью merge requests выполняет ревью.

Потрясающий инструмент в том плане, что:

• Можно видеть как отдельные коммиты, так и в целом что разработчик сделал по задаче, можно посмотреть сразу финальный результат.

• Можно отметить: «Да, вот это я здесь проверил, все выполнено, а вот это можно поправить», чтобы ревьюер не возвращался, к ранее проверенным участкам кода, после внесения исправлений по замечаниям.

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

Мы используем техники Git быстрого переноса между ветками. Это удобно, взяли cherry-pick и с помощью него перенесли какое-то исправление бага из одной ветки в другую одну или несколько веток. Представьте, что мы делаем такое же в конфигураторе 1С, это будет сравнение-объединение. Мы сразу попадаем на то, что нужно что-то выгрузить или загрузить. Контекстная подсказка формируется путем анализа окружения в конфигурации. Допустим, мы где-то определили структуру, ниже используем ее, и она уже подсвечивается, показывается, какие ключи есть в этой структуре.

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

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

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

Еще есть интересный плагин YaxUnit для тестирования. Мы его пробуем, начинаем использовать.

Заключение

Мы разрабатываем много разного API, и было бы здорово, если бы на базе описания стандарта OpenAPI можно было бы сформировать структуру метаданных в конфигурации.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.