YAxUnit: Путь к совершенству

YAxUnit – это современный инструмент для модульного и интеграционного тестирования на платформе 1С:Предприятие. Его название расшифровывается как Yet another xUnit – «еще один xUnit», потому что это еще один инструмент для модульного тестирования по аналогии с xUnitFor1c, xUnit for dot.Net и многими другими.

Это настоящий «швейцарский» нож для разработчика, который решил заняться тестированием. В YAxUnit все сделано, как вы любите – множество полезных функций собрано в едином удобном монолите.

Для примера, если вы разработчик из мира Java, вам для организации модульного тестирования понадобится:

• фреймворк для запуска тестов xUnit;

• AssertJ – для создания удобных утверждений-ассертов;

• Mockito – для работы с мокированием;

• Podam, Faker или Vaadin для генерации тестовых данных;

• и другие инструменты.

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

Наш инструмент тестирования состоит из двух компонентов.

• Тестовый движок – расширение для 1С, реализующее всю функциональность тестирования.

• Плагин для EDT – позволяет запускать тесты, выполнять отладку и просматривать отчеты с результатами тестирования в один клик.

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

Без лишней скромности скажу, что YAxUnit – один из лучших инструментов для модульного тестирования.

Но это не наша заслуга, это в первую очередь заслуга всего сообщества, потому что инструмент базируется и развивает идеи из других open-source-проектов, таких так:

• 1Unit от Александра Капралова, с которого и начался путь YAxUnit;

• xUnitFor1C, ADD и Vanessa Automation, из которых мы почерпнули немало идей.

Кроме этого, мы использовали подходы из некоторых инструментов не из мира 1С:

• JUnit для Eclipse, который лег в основу нашего плагина для EDT;

• UI и принципы запуска тестов из IntelliJ IDEA;

• Mockito из Java – из него мы взяли подходы по мокированию.

• Библиотека Faker из JavaScript для генерации тестовых данных – таких, как ФИО, ИНН, СНИЛС и так далее – отдельная благодарность Дмитрию Абрамову, который реализовал его аналог в рамках нашего инструмента.

Также хочу выразить большую благодарность всему open-source сообществу разработчиков 1С за их энтузиазм, идеи и вклад. Без их инструментов разработка 1С была бы не такой эффективной и удобной.

История развития YAxUnit

YAxUnit впервые был представлен на конференции Инфостарта в 2022 году, и за это время произошло множество доработок:

• выпущено более 12 релизов;

• закрыто больше 160 пулл-реквестов;

• а количество звезд на GitHub превысило отметку в 180.

Расскажу ключевые изменения и нововведения – что у нас появилось:

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

• В версии 23.01 был добавлен «Конструктор тестовых данных» с уникальным методом «Фикция()», позволяющий упростить подготовку тестового окружения.

• В версии 23.04 у YAxUnit произошло сразу несколько улучшений:

  • появился сайт с документацией;

  • получил развитие инструмент по мокированию – реализована возможность мокирования HTTP-сервисов и добавлен сбор информации о вызовах методов;

  • переработан вывод стека ошибок в EDT;

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

• В версии 23.05 добавлены:

  • механизм удаления тестовых данных, созданных вне транзакции, что полезно для тестов на клиенте, где транзакция может негативно повлиять на тест;

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

• В версии 23.07 добавлены:

  • инструмент для создания тестовых данных (ФИО, телефонов, ИНН и др.), работающий по аналогии с библиотекой Faker;

  • переопределение стандартных обработчиков событий – тоже полезное, но специфичное добавление, которое упрощает подготовку контекста.

• В версии 23.08 были реализованы:

  • загрузка данных из макетов-фикстур, к которым привыкли пользователи других инструментов;

  • внешняя компонента для вывода сообщений в консоль (удобно при логировании на CI/CD), постановки на паузу и работы с регулярными выражениями;

  • автотестирование исходного кода YAxUnit на Github CI.

• В версии 24.01 по просьбам сообщества добавили поддержку конфигураций с английским вариантом встроенного языка.

Инструмент постоянно растет и развивается:

• В версии 24.02:

  • реализован вывод результатов тестирования в формате Allure;

  • в EDT добавлены команды для генерации тестовых модулей и создания моков по шаблонам.

• В версии 24.03:

  • выполнен большой рефакторинг структуры модулей для разделения публичного и служебного API;

  • сильно переработана документация – она стала более полной, более понятной;

  • добавлен конструктор для создания объектов XDTO;

  • реализованы некоторые доработки в EDT по юзабилити и UI, расширены настройки конфигурации запуска

• В версии 24.04:

  • добавлен механизм внешних зависимостей;

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

• В версии 24.05:

  • внедрен сбор информации об окружении, которую можно использовать в тестах;

  • выполнены многочисленные доработки и оптимизации.

• В версии 24.08:

  • добавлена функция для установки фоновых управляемых блокировок для тестирования дедлоков;

  • появились экспериментальные дымовые тесты.

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

Работа над open-source проектом

А сейчас хочу поговорить о том, что нужно для создания успешного open-source продукта:

В первую очередь необходимо определиться с целями и задачами:

• Описать проблемы, которые решает ваш продукт.

• Определиться с целевой аудиторией: для кого продукт создается – для разработчиков, тестировщиков или бизнеса. Все это немаловажно и позволяет сообществу и пользователям понять, подходит им ваш инструмент или нет.

• Также имеет смысл посмотреть существующие решения и аналоги – понять, чем отличается ваш инструмент.

Немаловажно любить свой продукт. Разработка в open-source – это не просто работа с девяти до шести, это, в первую очередь, личная вовлеченность. Очень многое ложится на ваши плечи – чтобы проект рос и развивался, необходимо вкладывать силы, время и идеи. Просыпаться ночью и идти кодить свою идею, пока она не испарилась. Но при этом важно не жертвовать своей личной жизнью – находить баланс между работой и отдыхом. Такая вовлеченность не только развивает проект, но и помогает вам самим расти и совершенствоваться: прокачать свои софт и хард-скиллы, попробовать себя в разных ролях – как разработчик, РП, заказчик, тимлид, маркетолог.

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

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

• Используйте автоматизацию: CI/CD, статический анализ и тестирование. Это гарантирует, что все изменения проходят проверку, и упрощает процесс для внешних контрибьюторов.

• Будьте активны в коммуникации с сообществом.

• Помогайте новым участникам освоить проект. Это способствует росту сообщества и повышению интереса к вашему проекту.

• Поддерживайте актуальность проекта, исправляйте ошибки и добавляйте новые функции.

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

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

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

Следуя этим рекомендациям, вы сможете не только эффективно управлять своим open-source-проектом, но и построить сильное сообщество, которое будет активно поддерживать и развивать ваш проект.

Остановлюсь более подробно на некоторых моментах – в частности, на теме документации.

Я, как и многие другие разработчики, не очень люблю писать документацию. Мне гораздо интереснее решать технические вопросы – реализовывать новые функции, организовывать CI/CD, заниматься оптимизацией, изучать инструменты и так далее.

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

Однако по мере развития проекта и подключения к нему новых пользователей такой подход вызвал некоторые проблемы.

• Часто повторяющиеся вопросы. Некоторые вопросы были простыми и ответ на них был очевиден. Другие – более сложные и серьезные. Но ответы на эти вопросы отнимали время и отвлекали от работы.

• У пользователей возникали проблемы при внедрении инструмента – им было сложно разобраться в порядке работы только на основании той краткой документации, что у нас была. Необходимо было организовывать курсы, записывать видео, проводить дополнительную работу. Причем с этим столкнулись не только мы, но и сообщество. Некоторые люди записывали обзорные видео. Кто-то даже создавал полноценные видеоуроки. Сначала я думал, что эта активность закроет проблему, и я смогу использовать их материалы у себя – просто дать ссылки на них в документации. Но когда я стал внимательнее изучать эти видеоуроки, оказалось, что там встречаются ошибки и неточности. И это не вина авторов контента – это моя недоработка. Я сам не сумел четко выразить свои идеи и объяснить, как правильно пользоваться инструментом.

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

Преимущества ведения документации для open-source-проектов:

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

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

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

• Обеспечение долговечности проекта. Документированный проект проще поддерживать в долгосрочной перспективе.

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

Сложности ведения документации:

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

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

• Отсутствие мотивации. Многие разработчики предпочитают решать технические задачи, что нередко приводит к созданию поверхностной или неполной документации.

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

Мои подходы к работе с документацией:

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

2. Не откладывайте работу над документацией. Это важный аспект проекта. Создавайте документацию сразу вместе с кодом, не откладывайте на будущее.

3. Фиксируйте вопросы, не раскрытые или плохо раскрытые в документации, и периодически прорабатывайте их. Это позволит со временем улучшить покрытие документации.

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

5. Добавьте в шаблон PR пункт об обновлении документации. Это поможет вам и контрибьютерам отслеживать этот момент.

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

7. Старайтесь искать ответы в документации, а не сразу в коде. Это позволяет лучше понять опыт пользователя.

Качественная документация – это ключевой элемент успеха open-source проектов. Она помогает не только текущим пользователям, но и новым участникам

Еще один немаловажный аспект жизни любого open-source проекта – это взаимодействие с сообществом.

Один из основных инструментов для такого общения – это issue-трекер, относительно простой, но достаточно мощный механизм, имеющий большое количество преимуществ:

• Прозрачность работы над проектом. Благодаря issues пользователи продукта и участники разработки видят: какие есть проблемы; какие планируются улучшения; как развивается продукт. Это способствует формированию доверия к проекту.

• Обратная связь от сообщества. Через issues пользователи могут вносить предложения, задавать вопросы, регистрировать ошибки. Это помогает основным разработчикам лучше понимать, какие проблемы актуальны для сообщества, как сделать продукт более качественным и соответствующим ожиданиям пользователей.

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

• Планирование релизов. С помощью issues можно распределять задачи, ставить приоритеты, контролировать ход работ. Для этого в списке issue есть метки (labels), позволяющие классифицировать тикеты по типам (ошибка или заявка) и выставлять им приоритеты.

Рекомендации:

• Четкие заголовки и описания. Заполнение issue часто бывает недостаточным или некорректным. За этим нужно следить и требовать от сообщества, чтобы люди писали более понятные заголовки и описания – отразить эти требования в документации по проекту.

• Шаблоны для issues. GitHub позволяет создавать шаблоны для разных типов заявок (баги, предложения, задачи). Например, для описания ошибки можно заранее подготовить шаблон с полями, куда нужно заполнить: шаги воспроизведения, ожидаемое и фактическое поведение, и дополнительные данные (версия ОС, версия программы и т.д.).

• Использование меток (Labels). Для удобства анализа и работы с issues используйте метки – они помогают быстро классифицировать и фильтровать issues:

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

  • по приоритетам – метки также можно использовать для указания важности задач, например: high priority, low priority, urgent;

  • по уровню сложности – для привлечения новых разработчиков можно добавлять метки, указывающие уровень сложности задачи, например good first issue, beginner-friendly, чтобы новички могли легче начать.

• Четкая и конструктивная коммуникация. При обсуждении проблем оставайтесь вежливыми и конструктивными. Если issue не может быть решен, дайте четкое объяснение, почему. Если issue требует дополнительной информации, попросите ее корректно и доброжелательно.

• Отслеживание активности и приоритизация. Регулярно отслеживайте активность в issues, чтобы не упускать важные проблемы и предложения. Реагируйте на issue, не оставляйте их без внимания.

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

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

Как обеспечить обратную совместимость:

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

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

• Следуйте стандартам вендора. Это снижает затраты на поддержку и спасает от ошибок в будущем.

• Физически разделяйте публичный и служебный программный интерфейс. Несмотря на то, что разделение по областям может казаться достаточным, оно не гарантирует полной безопасности от нежелательного использования служебных методов. Физическое разделение API на публичный и служебный модули – более надежный подход. Это не только упрощает поддержку кода, но и защищает проект от случайного использования внутренней логики со стороны внешних разработчиков.

• Для удобного отслеживания изменений используйте commit convention – стандартизированные правила оформления сообщений к коммитам. Это поможет четко фиксировать тип изменений (исправления ошибок, обновления документации, реализация новых возможностей, тесты и так далее), улучшая понимание истории проекта и упрощая генерацию changelog. Ясные и структурированные сообщения коммитов позволяют легко прослеживать, какие изменения могут затронуть обратную совместимость.

• Тестирование обратной совместимости. Не забывайте про тестирование – и про регрессионное перед релизами, и во время разработки. Оно также помогает выявлять ошибки заранее.

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

• Семантическое версионирование (SemVer) – оно помогает пользователям четко понимать, чего ожидать от новой версии, и избегать обновлений, которые могут привести к поломке используемой функциональности. В системе SemVer используются три цифры X.Y.Z, указывающие тип изменений в каждой новой версии проекта:

  • X – мажорные изменения (вносят обратимые изменения, ломающие совместимость);

  • Y – минорные изменения (новые функции, которые не ломают совместимость);

  • Z – патч-версии (исправление багов и незначительные улучшения).

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

• Версионирование API. Использование версий APi позволяет поддерживать старые и новые функции параллельно. При этом пользователи смогут обновляться постепенно, переходя на новую версию API, сохраняя при этом стабильную работу своих тестов.

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

• Документация изменений. Обязательно фиксируйте все изменения в логах версий – changelog или release notes. Благодаря им пользователи смогут заранее узнать, что именно изменилось в новой версии, и как это может на них повлиять. Это особенно важно для обновлений, которые затрагивают критические части движка.

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

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

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

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

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

  • Как начать работу с проектом (инструкции по сборке, запуску и тестированию).

  • Инструкции по ведению документации и созданию issues

  • Как вносить вклад (pull request workflow, кодстайл).

• Используйте теги для задач. Помечайте задачи, которые подходят для новичков, тегами вроде «good first issue» или «beginner friendly». Это позволяет новым контрибьюторам легко находить задачи, с которых можно начать. Чем проще будет для них первый вклад, тем выше вероятность, что они захотят продолжить работу с проектом.

• Публично благодарите контрибьютеров. Упоминайте контрибьютеров в changelog, release notes или в социальных сетях. Это показывает, что их вклад ценен и важен для проекта.

• Предоставьте четкую дорожную карту (roadmap). Разработайте и опубликуйте дорожную карту проекта с краткосрочными и долгосрочными планами. Это позволяет контрибьюторам понимать, какие направления развития приоритетны, и выбрать задачи в зависимости от своих интересов и возможностей.

Кроме взаимодействия с сообществом при работе с open-source-проектом есть и другие проблемы.

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

• Различные окружения и IDE. Изначально YAxUnit был спроектирован для работы в среде EDT, что создало определенные ограничения для пользователей, работающих в конфигураторе. В дополнение к этому, периодически возникают проблемы работы на различных версиях конфигурации. Это привело к ряду проблем, таких как сложность запуска и просмотра результатов тестов, а также недостаточная поддержка контекстной подсказки. Выход, который мы нашли:

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

  • Разработать подробные руководства и документацию по использованию инструмента в различных средах разработки для упрощения работы новых участников.

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

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

  • Вовлекайте сообщество через открытые обсуждения.

  • Разделяйте задачи на небольшие и выполнимые шаги, чтобы участники могли быстрее видеть результаты своей работы

  • Признавайте и вознаграждайте вклады разработчиков через упоминания и благодарности в сообществе.

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

• Излишний энтузиазм – он тоже иногда приводит в итоге к выгоранию и забрасыванию работ над продуктом.

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

  • Приоритизируйте задачи. Определите, какие задачи наиболее важны и приносят наибольшую пользу проекту. Не пытайтесь взяться за все сразу.

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

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

• Временные затраты на поддержку проекта. Есть несколько способов, которые помогут оптимизировать процесс разработки, не жертвуя качеством:

  • Автоматизация процессов тестирования и CI/CD: Использование автоматизированных тестов позволяет быстро проверять работоспособность кода после изменений, что снижает необходимость ручной проверки и уменьшает риск ошибок. А инструменты непрерывной интеграции и доставки позволяют автоматически запускать тесты, сборку и развертывание проекта, что сокращает время на эти рутинные задачи.

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

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

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

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

Организация CI на GitHub

Самый популярный инструмент статического анализа, о котором, наверное, знает каждый 1С-ник – это SonarQube. Он позволяет значительно повысить уровень качества решений и улучшить процессы разработки. Но стоит учитывать, что из коробки SonarQube ничего не знает об 1С. Это можно исправить с помощью open-source плагина от сообщества BSL LS, за что им огромная благодарность. Благодаря их работе любой может с легкостью проверить свой код на соответствие стандартам и бест-практис, на раннем этапе выявить ошибки и отклонения от стандартов, а также нарушения принципов DRY и SOLID.

Мы для автоматизации статического анализа используем бесплатный SonarQube-сервер с подключенным плагином BSL LS, предоставленный проектом OpenBSL. Для его подключения вашего open-source проекта к этому серверу нужно обратиться к Никите Федькину (Грызлову). Очень многие открытые решения для 1С:Предприятия и OneScript уже подключены к OpenBSL, в них вы можете подсмотреть примеры настройки.

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

Кроме этого, для контроля качества мы на GitHub создали и развиваем систему тестирования продуктов 1С. Она позволяет запускать тесты для каждого пулл-реквеста и сразу видеть результаты их прохождения в разных окружениях: Linux, Window, под различными локалями (английской и русской), на различных версиях платформы.

Есть только одна проблема – для тестирования на GitHub используются утилиты ibcmd и ibsrv, которые позволяют запускать 1С только в режиме тонкого клиента. Из-за этого тестирование у нас только в тонком клиенте, и нужно будет продумать этот вопрос в дальнейшем.

Еще один эксперимент – мы сейчас экспериментируем с авторевью, чтобы сократить время на проверку кода. Для этого используется инструмент CodeRabbit на основе LLM-моделей. Он более-менее умеет справляться с кодом 1С, умеет его читать и понимать, умеет читать тесты и предлагать полезные варианты исправлений. Правда, с генерацией новых тестов он пока справляется не очень хорошо, но иногда у него получаются неплохие результаты.

Кроме тестирования, мы активно развиваем автоматизацию других процессов.

Например, используя готовые шаги GitHub Actions и свои наработки удалось организовать автоматический выпуск релизов, включающий:

• сборку артефактов;

• формирование changelog на основании PR и закрытых issues;

• прикрепление артефактов к релизу;

• публикацию draft версии, которая после ревью публикуется разработчиком

Также мы автоматизировали процесс генерации и публикации API – на сайте документации автоматически публикуется описание всех публичных методов YAxUnit. Для этого была разработана java-утилита, которая с помощью bsl ls автоматически формирует описание на основании документирующих комментариев и добавляет его к основной документации.

Это еще один пример успешного использования open-source. Я не стал изобретать велосипед, а переиспользовал готовое отличное решение и получил в короткие сроки отличный инструмент. Плюс к этому мои потребности и выявленные нестыковки будут перенесены в основной инструмент. Обоюдная польза.

Небольшой итог
 

Open-source-решения плотно входят в нашу жизнь – появляется много различных проектов. Я бы хотел, чтобы больше людей вливалось в это движение. Это позволит снизить порог входа в open-source-проекты и упростить их поддержку.

Работа с open-source проектами позволяет вам столкнуться с различными новыми технологиями, получить новый опыт и попробовать себя в различных ролях. Это сильно развивает вас как специалиста и позволяет создавать классные инструменты, благодаря коллаборации и поддержке всех заинтересованных лиц.

Вопросы и ответы

Расскажите подробнее про эксперименты с CodeRabbit. Вы его используете для код-ревью или для чего-то еще?

Сейчас мы в основном применяем CodeRabbit для код-ревью, плюс я пытаюсь его научить писать тесты. По сути, это LLM-ассистент, который анализирует контекст вашего репозитория и выдает рекомендации.

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

А как по вашему опыту, CodeRabbit для код-ревью у вас полезен оказался или нет?

Польза от него есть. Он действительно находит некоторые проблемы и предлагает решения. Но не всегда правильно – с ним пока еще надо быть осторожным.

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

Он выступает как некоторый ассистент, который иногда может подсказать что-то дельное. Но это именно рекомендации.

Есть ли у вас какая-то статистика по использованию YAxUnit? Например, по количеству скачиваний релизов с GitHub либо по тому, в каких компаниях он используется? Насколько вообще ваш инструмент вошел в рынок?

Статистика по скачиваниям актуального релиза есть на основной странице проекта в GitHub – она формируется автоматически.

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

Мы сейчас планируем запускать дымовые тесты на обычных формах. Какие у них есть ограничения для ретроградов?

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

Есть ли у вас наработки на тему покрытия тестами (code coverage)? Что-то планировалось или нет?

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

Вы делаете этот open-source в рамках компании? Или по ночам? Потому что непонятно, как обосновать бизнесу необходимость тратить его время на такую open-source-разработку. В итоге приходится сидеть по ночам.

Сложный вопрос. Все зависит от целей.

Если вы хотите реализовать решение для себя – лучше изначально его вести как open-source в свободное время или по ночам. Так проще. Будет меньше проблем с согласованием и обоснованием.

А если хочется, чтобы вам за это платили, нужно обосновать, как проект помогает внутренним процессам или повышает узнаваемость компании (например, через HR-бренд).

Просто вы еще рассказывали, что мотивация пропадает – мне кажется, это происходит, в том числе, из-за того, что проект приходится делать в свое свободное время.

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

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

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

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