Современный инструментарий 1Сника

Разбираться в технологиях мне интересно с детства. В то время я устанавливал программы с дисков просто чтобы понять, как они работают и для чего нужны. Alcohol 120%, DAEMON Tools, ArtMoney, AIMP, скины для Winamp – все, что было на дисках – все было установлено. Тогда я понял, что программы есть практически для всего, и можно не изобретать велосипед, а пользоваться уже существующими решениями.

А когда я пришёл в мир 1С, меня очень удивило, что внешние инструменты здесь почему-то мало используются.

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

Об этой карте стека технологий для 1С мы сегодня и поговорим.

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

Но мы-то с вами знаем, что он на самом деле работает в «1С:Бухгалтерии предприятия, редакция 3.0» на платформе 8.3. И что сама 1С не монолитна в своей структуре.

1С можно условно разделить на две части:

• Пользовательскую – для работы с информационной базой в режиме 1С:Предприятие (среда выполнения).

• И конфигуратор (среда разработки), где можно вносить в конфигурацию изменения и обновлять ее на новую версию.

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

Ведь если пойти еще глубже, выяснится, что:

• Клиентов может быть несколько. Причем они могут быть разные – толстые и тонкие. А еще с 1С можно работать через веб-клиент – для этого базу 1С нужно будет опубликовать на веб-сервере.

• Серверы 1С могут объединяться в кластеры серверов, чтобы все это работало вместе.

• А база данных может быть не только файловая, но и, например, на PostgreSQL.

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

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

Это важный инструмент в хороших командах.

Потом, со временем, мы понимаем, что разработку 1С можно вести не только в конфигураторе. Есть еще и другие среды разработки, которые тоже умеют работать с 1С и даже запускать отладку из него – например, Enterprise Development Tools или VS Code.

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

Git и хранилище – это системы контроля версий.

• Одна из них – централизованное хранилище, которое всегда хранит всю историю в одном месте.

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

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

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

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

И здесь важно разделять два понятия, которые иногда путают: Git и GitHub – это не одно и то же.

• Git – это сама система контроля версий.

• А GitHub, GitLab, BitBucket и другие подобные решения – это платформы, где можно хранить удаленные Git-репозитории и организовывать совместную работу.

  • GitLab обычно разворачивают внутри компании на собственных серверах.

  • GitHub используют как облачный сервис.

  • Или размещают репозиторий на одном из альтернативных облачных Git-серверов – например, в BitBucket.

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

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

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

Кроме встроенных проверок существуют еще и отдельные инструменты статического анализа.

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

• Также есть 1С:Автоматизированная проверка конфигураций (АПК), которая проверит код всей вашей конфигурации на соответствие стандартам разработки. Выдаст миллион замечаний, вы посмотрите, вздохнете и продолжите работать, как раньше.

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

Чтобы все эти проверки запускались не вручную, а автоматически каждую ночь, существует набор практик CI/CD.

И самый популярный у 1С-ников инструмент CI/CD – это Jenkins. Его чаще всего используют для автоматизации получения исходников из среды разработки, чтобы передать их в инструмент статического анализа. Основная причина его популярности в том, что вы можете самостоятельно развернуть и настроить Jenkins у себя на компьютере. Причем он может делать что угодно – даже суперсложные вещи. Но за ним нужно ухаживать: обновлять, бэкапить, следить, чтобы не упал.

При этом Jenkins далеко не единственный вариант. Если команда работает с GitHub, можно попробовать GitHub Actions. А если у вас Gitlab, то там есть собственный механизм – GitLab CI.

Или можно использовать Travis CI – это такой же запускатор проверок, тестов и других операций в рамках CI/CD. И хотя в 1С-сообществе его используют довольно редко, я его сюда тоже добавил для разнообразия.

А теперь представьте: сначала мы работали только с базой 1С:Бухгалтерии, а потом у нас появилась еще и 1С:ЗУП. И возникла потребность, чтобы эти две базы как-то друг с другом обменивались.

Обычно для такого обмена используется специальное решение – 1С:Конвертация данных.

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

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

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

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

Дальше нашей системе понадобилась интеграция с мессенджером, а точнее сразу с двумя – с Телеграм и МАКС. Поскольку у каждого из них свой API, свои особенности и форматы сообщений, напрямую обмениваться будет неудобно. Нужна промежуточная система. Один из вариантов – Система взаимодействия 1С.

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

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

Если же Система взаимодействия вам по каким-то причинам не подходит, есть ещё один интересный вариант – Открытый пакет интеграций (ОПИ).

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

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

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

Автотесты помогают:

• Выявить проблемы на ранних этапах, ещё до того, как они повлияют на пользователей.

• Контролировать качество внедряемых доработок – убедиться, что новая функциональность корректно работает в рамках текущей системы

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

Один из самых известных инструментов автоматизированного тестирования в сообществе 1С – Vanessa Automation.

Помимо Vanessa Automation есть еще и 1С:Тестировщик. Это бесплатный инструмент от фирмы «1С», наследник 1С:Сценарного тестирования, который тоже позволяет выполнять сценарные тесты. Он разрабатывается в том же отделе, что и 1С:Бухгалтерия предприятия. Все наши тесты написаны и работают как раз на нем.

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

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

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

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

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

Короче, очень крутая штука.

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

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

Вы спросите: «Какое отношение это имеет к 1С, если у нас основная работа происходит с информационной базой? И вообще, как можно управлять всеми 1Сками одновременно, да еще и в изолированных средах?» Оказывается, в этом направлении давно ведет исследования Дмитрий Овчаренко. Можно у него выяснить, как Kubernetes работает с 1С, и куда все это движется.

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

Самый очевидный вариант – отправлять данные напрямую. Сайт вызвал HTTP-сервис 1С, передал заказ, 1С его приняла – все замечательно.

Но что произойдет, если в этот момент информационная база недоступна? Или сайт недоступен? Запрос может просто не дойти.

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

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

Из популярных инструментов здесь можно выделить RabbitMQ, Kafka и 1С:Шина.

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

• Kafka – наоборот, представляет собой долговременный журнал событий, сообщения в котором не удаляются сразу после прочтения. Сообщения пишутся в топик, а получатели сами тянут (pull) их, когда хотят, и могут перечитывать старые. Удобно использовать для больших объемов данных, например, логов, телеметрии или огромных объемов изменений данных, где важна история событий.

• А еще есть 1С:Шина. Она, наверное, больше похожа на RabbitMQ, чем на Kafka. Это полноценная шина данных с очередями сообщений, где они хранятся на диске до подтверждения доставки и передаются по сложным правилам маршрутизации.

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

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

И первый инструмент, который в свое время меня очень впечатлил – Fiddler.

Fiddler относится к категории снифферов – это анализатор трафика и прокси-сервер.

Fiddler используется для регистрации, проверки и изменения трафика HTTP и HTTPS между компьютером и веб-сервером.

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

Другой инструмент здесь же в веб-разработке – это Swagger UI, который визуализирует OpenAPI-описание веб-сервиса в виде интерактивной документации.

Это «Инструкция по API», которую готовит сам сайт – генерирует красивую HTML-страничку с описанием своего API, т.е. всех доступных для сайта запросов (эндпоинтов). На этой странице мы даже без внешней системы (то есть без 1С) можем просто поменять данные и проверить, что все хорошо работает – можем кликать и тестировать прямо там, без кода.

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

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

В Postman можно сохранять запросы к нашему API в коллекции, а потом последовательно их выполнять и проверять ответы – все ли у нас там хорошо.

Хотим проверить API – свой или чужой, с которым используется интеграция, неважно – сохраняем в Postman набор GET и POST запросов с данными, отправляем их на сервер и смотрим ответ. Есть коллекции для повторных проверок и автоматизация. Удобно проверять API, как отправлять посылки и смотреть, что внутри.

И последний инструмент, о котором я здесь хочу рассказать – это ngrok, который позволяет открыть туннель наружу.

Например, у нас на локальном компьютере, на localhost (127.0.0.1) развернут HTTP-сервис 1С. По этому адресу его никто снаружи не увидит, его видно только с локального компа. Но вам нужно проверить, что он работает – например, чтобы показать проект друзьям или потестить вебхуки. Ради этого необязательно сразу публиковать разработку на боевом сервере, ngrok позволяет открыть временный туннель наружу. Вы запускаете его, получаете внешний URL (типа abc.ngrok.io), он нам дает ссылку на наш сайт, и мы можем извне уже проверять.

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

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

Например, Vanessa Automation умеет записывать результаты выполнения автотестов для 1С (с шагами, скринами, ошибками) в JSON-файл. То же самое можно настроить в Postman.

А Allure с помощью команды allure generate собирает их в красивый HTML-сайт с графиками и трендами – открываешь в браузере и видишь, какие тесты прошли, какие упали, сколько времени выполнялись, какая была история предыдущих запусков.

Если вдруг нужно мониторить физические машины, для этого есть Zabbix. Он позволяет раскидать на все пользовательские машины агентов, и если вдруг там закончилось место, проблемы с памятью или с CPU – при приближении значения к пороговому информация об этом поступит через SMS или уведомление в мессенджер. Агенты на раннерах с заданным интервалом передают метрики в центральный сервер Zabbix, триггеры проверяют правила (если CPU>90% – алерт по SMS), а графики строятся автоматически.

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

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

А потом с помощью Grafana всю эту информацию можно вывести в виде красивых дашбордов с графиками в реальном времени, алертами и фильтрами – обновляется само.

Связка Prometheus и Grafana особенно полезна для сбора информации по проблемам в системе и востребована у технических специалистов – разработчиков и службы поддержки.

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

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

Самая известная BI-система для 1С – это 1С:Аналитика, которая как раз позволяет собирать информацию из нескольких баз данных и агрегировать ее в одном месте.

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

В качестве зарубежного аналога можно посмотреть Power BI от Microsoft – он тоже может применяться для сложных аналитических отчетов по данным 1С.

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

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

Наиболее часто для анализа логов применяется ELK-стэк, куда входят Elasticsearch, Logstash и Kibana.

• Logstash собирает сырые логи из файлов, парсит их, разбирает на части, фильтрует и отправляет дальше.

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

• А Kibana позволяет рисовать на основании систематизированных логов дашборды в браузере – составлять графики, карты ошибок, видеть тренды и алерты.

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

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

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

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

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

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

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

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

• Еще один инструмент, предназначенный специально для 1С – это MAKER STUDIO. В нем мы просто перетаскиванием готовых элементов в браузере накидываем форму, похожую на 1С – там есть желтая кнопка «Провести и закрыть», просмотр движений документа «ДтКт» и другие характерные составляющие. Аналитики могут его использовать, чтобы нарисовать интерфейс, согласовать его с заказчиком, а потом отнести разработчику. Либо скормить картинку искусственному интеллекту, чтобы он по ней уже написал то, что должно получиться.

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

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

И здесь самым популярным инструментом в 1С-сообществе стал OneScript – движок, который позволяет запускать скрипты, написанные на 1С-подобном языке. Поэтому, если вы уже знаете встроенный язык 1С, вы легко освоитесь и с OneScript.

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

Такую же автоматизацию обеспечивает и инструмент от фирмы «1С», 1С:Предприятие.Элемент Скрипт – бывший Исполнитель.

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

Для скриптов, написанных на языке 1С:Элемент Скрипт, также поставляется специальная среда выполнения, оснащенная средствами DevOps и CLI. Удобно использовать для быстрой разработки и обучения.

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

Например, у нас в одном из репозиториев живут Python-скрипты для проверки TODO-комментариев в коде и формах, и мы их запускаем наравне с другими проверками. Поэтому здесь можем использовать для автоматизации любые инструменты – не только на 1С. Смотрите шире, и работать будет интереснее.

Отдельный вопрос, который возникает практически всегда, когда заходит разговор о разработке – это где вести задачи?

Вариантов таск-трекеров для разработки множество, но я здесь собрал только самые распространенные.

• Первый и самый используемый в мире – это Jira. Согласно опросу Stack Overflow Developer Survey 2024, Jira была самым распространённым из перечисленных инструментов совместной работы: её указали 51,4% ответивших на этот вопрос. Jira входит в линейку продуктов фирмы Atlassian, и хотя у нас она сейчас недоступна, как массовое явление ее стоит отметить.

• Дальше – Trello. Он популярен из-за удобной Kanban-доски и наглядной визуализации задач. Там можно нарисовать колонки «План», «Анализ», «Разработка», «Тестирование», «Релиз» и интерактивно перевешивать задачу между разными статусами. Удобно для небольших команд и фрилансеров.

• Яндекс Трекер особенно популярен в последнее время в российских ИТ-командах. Ориентирован на разработку, имеет поддержку Agile-проектов и интеграцию с Яндекс.Облаком.

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

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

Для изучения стандартов рекомендую сайт Игоря Апресова v8std.ru, где стандарты 1С описаны понятным языком – что от нас требуется, и как это использовать.

Стандарты лежат в основе проведения код-ревью внутри команды, и на них опирается большинство проверок BSL Language Server и АПК, а также другие инструменты статического анализа.

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

Помимо классического 1С, в нашей экосистеме есть еще и 1С:Предприятие.Элемент. Это технология, которая позволяет создавать красивые приложения, ориентированные не только на бизнес, но и на конечного пользователя – кабинеты, витрины и т.п.

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

И еще есть мобильная платформа, с помощью которой можно легко создавать мобильные приложения и публиковать их в различных маркетах: App Store, Google Play, Huawei AppStore. Встроенный в платформу 1С сервис публикации сильно упрощает подготовку дистрибутивов для магазинах приложений, и заморочек с этим будет гораздо меньше, чем при публикации вручную.

Куда двигаться дальше

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

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

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

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

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