Автоматизированная проверка конфигураций 1с инструкция

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

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

Техническое качество решений

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

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

Основные возможности

АПК выполняет проверку технического качества конфигураций в следующих вариантах:

Разовая проверка конфигурации на соответствие стандартам разработки

• Разовая автоматическая проверка конфигураций на соответствие актуальным стандартам разработки конфигураций на платформе «1С:Предприятие 8» для получения детального представления о качестве конкретной версии прикладного решения (например, при сертификации на статус «1С:Совместимо»).

Регулярная автоматическая проверка конфигурации на соответствие стандартам разработки

Это рекомендуемый вариант для непрерывной интеграции (CI, англ. Continuous Integration) с целью выявления ошибок и несоответствий стандартам на ранней стадии разработки. Непрерывная интеграция — практика частой сборки и тестирования продукта с целью выявления и устранения ошибок почти сразу же, как только они были привнесены.

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

• Гибкая настройка области и графика проверки:
  • проверка конфигурации по расписанию для планирования запуска проверки по определенному удобному графику;
  • автоматическое обновление проверяемой конфигурации из сетевого хранилища конфигурации (при коллективной разработке); при этом выполняется инкрементальная проверка только последних измененных объектов, что многократно ускоряет проверку в целом и позволяет выполнять проверки чаще.
• проверка как групп требований, так и отдельных стандартов, в том числе отдельная платформенная проверка конфигурации;
• проверка всех или только указанных объектов конфигурации;
• проверка объектов конфигурации с учетом заданных исключений.

Формирование результатов проверки конфигурации в виде настраиваемых сводных отчетов и быстрые операции с выявленными ошибками:

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

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

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

Пакетный режим запуска с выгрузкой результатов проверки в формат JUnit.

Интеграция с «Системой проектирования прикладных решений» (СППР) для работы с ошибками проверяемой конфигурации непосредственно в СППР.

Проверка орфографии

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

Сервисные возможности

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

Сравнение качества различных конфигураций

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

Расширяемость

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

Порядок распространения и использования

Получить дистрибутив финальной версии могут зарегистрированные пользователи системы «1С:Предприятие 8», имеющие действующую подписку на информационно-технологическое сопровождение (ИТС), а также партнеры фирмы «1С».

Дистрибутив финальной версии распространяется следующими способами:

1. в составе диска ИТС;
2. на сайте поддержки пользователей.

Для использования финальной версии «1С:Автоматизированная проверка конфигураций» необходима платформа «1С:Предприятие 8» версии 8.3.6 и выше.

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

Снижение качества кода со временем

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

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

© Источник: книга «Чистый код», Роберт Мартин 

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

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

Кроме проблемы производительности, в продуктах с низким качеством кодовой базы «фактор автобуса» равен или стремится к 1.

Фактор автобуса (bus-factor) — это число человек, которое нужно сбить автобусом, чтобы проект перестал развиваться. Хорошим значением является количество участников команды (звучит жестоко, но описывает ситуацию на проекте). 

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

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

Воспринимаемая сложность кода

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

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

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

В нашем представлении мы реализовали «красивую картинку».

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

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

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

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

Критерии качественного кода

Если спросить 10 начинающих разработчиков: «Что такое качественный код?», они могут перечислить такие характеристики, как

• простой,
• понятный,
• поддерживаемый,
• работающий.

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

Прямые отголоски на SOLID в стандартах 1С найти сложно, но их можно найти в типовых конфигурациях и библиотеках.

Обратим внимание на объект Отчет. Для его построения в платформе используются объекты КомпоновщикМакета, СхемаКомпоновкиДанных, КомпоновщикНастроек, МакетКомпоновкиДанных, ПроцессорКомпоновкиДанных, ПроцессорВывода. Такое разнообразие объектов позволяет легко расширить функционал. Например, процессоров вывода реализовано два: в коллекцию и табличный документ, а замена одного на другой не нарушает всю цепочку. Такое разделение указывает на принципы S и L.

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

Хорошим примером принципа D будет подсистема Организации. В каждой конфигурации свой объект Организации и структура его хранения. Получалось, что подсистемы БСП зависели от реализации в типовых конфигурациях. Это усложняет внедрение и обновление функционала. Подсистема Организации реализовывает интерфейс и структуру описывающие абстрактную организацию с предопределенными полями. Что позволяет развернуть зависимость на обратную. БСП зависит от интерфейса и конфигурация зависит от него же, так как его реализует.

YAGNI («You aren’t gonna need it»; с англ. — «Вам это не понадобится») — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности. 

SOLID говорит нам, что мы должны быть готовы к предстоящим изменениям, а YAGNI утверждает, что не следует писать лишнего, нужно делать рефакторинг в момент необходимости. Данные методики немного противоречат друг другу. Получается, что за все время развития программирования мы так до конца и не сформулировали, что такое качественный код. Мировая практика показывает, что даже если не известно, как «хорошо», то все равно очевидно, когда «плохо». И отсюда вывод: не будем делать «плохо» и постепенно приблизимся к границе «хорошо».

Практика плохих и хороших решений собрана в системе стандартов разработки на «1С:Предприятие». Стандарты регулярно обновляются и расширяются, так как и сама платформа, и мир вокруг нее развиваются.

Для более детального анализа качества кода можно выделить ряд показателей:

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

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

Работоспособность

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

Покрытие тестами

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

Абсолютно не важно какой вид тестирования вы используете. Разные тесты подходят в разных ситуациях. У себя мы большинство задач решаем через сценарные тесты. Об этом мы подробнее писали в статье «Подходы к сценарному тестированию на примере 1С:Общепит и 1С:Сценарное тестирование».

Наименования

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

Плохие наименования ведут к лишним вопросам, на которые приходится тратить время, как на рисунке ниже.

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

Оформление

Опытные программисты с лёгкостью улавливают закономерности в коде. И если сущности одинаково оформлены, их проще вычленять из текста. Хорошее оформление увеличивает скорость чтения кода в разы.

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

Компактность

Компактность говорит нам о том, что по возможности следует сокращать количество строк, не увеличивая сложность кода.

Рассмотрим следующий код:

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

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

Операторы ветвления сами по себе сложные, а их вложенность особенно мешает восприятию.

Комментирование

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

Рассмотрим пример:

Комментарий «Настроим блокировку элементов формы» уже полностью содержится в имени процедуры «Блокировать элементы формы» и его можно безболезненно удалить.

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

Дублирование

Возникает на проекте по нескольким причинам:

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

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

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

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

Качество кода и производительность

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

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

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

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

Делаем и сохраняем код качественным

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

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

Для упрощения работы с качеством нам понадобится инструмент для измерения показателей качества, обнаружения ошибок, отслеживания динамики изменений на проекте. В сообществе прижилось два инструмента для этих задач «Автоматизированная проверка качества» и SonarQube.

1С:Автоматизированная проверка конфигураций

Данный продукт предназначен для проверки конфигураций на платформе «1С:Предприятие 8» на соответствие принятым стандартам разработки и иных технических требований.

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

Продукт разрабатывался под 1С и в нем предусмотрены ряд моментов свойственным только этой группе продуктов:

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

Поддерживает работу как с хранилищем конфигураций, dt и cf файлами, так и с выгруженной в файлы конфигурацией.

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

Вход в инструмент происходит легко. Эта конфигурация 1С, которая говорит с пользователем на понятных ему терминах. Разобраться, что к чему достаточно просто. Для выполнения первой проверки достаточно заполнить карточку с описанием конфигурации.

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

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

SonarQube

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

SonarQube позволяет решать задачи по:

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

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

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

При своей работе инструмент потребляет существенные ресурсы процессора и оперативной памяти. Но скорость его работы высокая, анализ даже самых крупных конфигураций на ограниченных мощностях не превышает 1 часа. Например: анализ ERP на 12 ядрах и 16 Гб оперативной памяти занимает около 20 минут в сонар сканере.

За разнообразие возможностей приходится платить высоким порогом входа. Сначала потребуется разобраться с компонентами самого SonarQube, организовать выгрузку хранилищ в git, организовать запуск анализа выгруженных исходников. Общая схема может например выглядеть так:

Как настроить каждый из этих компонентов в рамках данной статьи описывать не будем. Только рассмотрим их функции.

GitConverter выполняет одностороннюю синхронизацию хранилища конфигурации с репозиторием git. Для хранения центрального git репозитория мы выбрали продукт gitlab.

SonarQube состоит из трех компонентов:

1. База данных, мы используем postgresql.
2. Sonar Scanner. Выполняет анализ исходного кода. Формирует список ошибок и показателей для ядра. Располагаться должен на одном сервере с анализируемыми данными.
3. Сервер SonarQube. Занимается обработкой собранных ошибок и показателей. Записью результатов в базу данных. Взаимодействие с пользователем посредством веб-интерфейса.

Jenkins управляет доставкой исходного кода с gitlab и запуск сканера. Запуск может происходить по расписанию или триггеру (например, изменению исходного кода).

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

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

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

Все замечания делятся на три основных вида.

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

Уязвимости указывают на возможные проблемы с безопасностью.

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

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

Организация процесса работы

На проектах разработки мы попробовали разные подходы к работе с качеством кода.

Сначала использовали АПК. За блоками в конфигурации были закреплены ответственные. Раз в неделю проверяли конфигурацию и все найденное исправляли или отмечали как особенность. Занимало это около трех-четырех часов на разработчика в неделю.

Сложности использования АПК

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

Переход на SonarQube

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

Очередь за 1C:EDT + SonarQube

Сейчас мы перешли на разветвленную модель разработки. На одном из проектов используем разветвленную модель на хранилищах, а второй полностью перевели на разработку в 1C:EDT.

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

Проверять теперь мы стали не только главное хранилище/ветку, но и каждую «ветку» отдельно. Такая проверка позволяет исправить все замечания до попадания кода в главное хранилище/ветку.

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

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

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

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

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

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

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

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

Статьи по теме качества кода, упомянутые выше:

• Подходы к сценарному тестированию на примере 1С:Общепит и 1С:Сценарное тестирование.
• Jenkins в разработке конфигураций 1С.

Проверка конфигурации

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

Выполнение проверки конфигурации также можно выполнить с помощью параметра командной строки пакетного режима запуска /CheckConfig (ключи режимов проверки также указаны в перечне тестов механизма).

Для выполнения проверки конфигурации выберите пункт “Конфигурация —
Проверка конфигурации…“. 

Несущественные предупреждения проверки конфигурации

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

• Пустой обработчик (для обработчиков оповещений в программных модулях);
• Неразрешимые ссылки на объекты метаданных (в формах и в справке);
• Неразрешимые ссылки на картинки (в формах);
• Неправильные пути к данным (в формах).

Кроме того методика поиска и исправления подобных мест отсутствует.

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

1С:Автоматизированная проверка конфигураций

Общая информация о конфигурации

«1С:Автоматизированная проверка конфигураций» (АПК) предназначена для автоматизированной проверки конфигураций, разработанных на платформе «1С:Предприятие 8», на соответствие стандартам и иным требованиям технического характера.

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

Previous ArticleЭлектронные весы

Сервис предназначен для разработчиков «1С-Совместно» на платформе «1С: Предприятие 8» и включает в себя несколько видов проверок:

• 1С: Предпроизводственная проверка (5П — проверка программных продуктов перед производством).
• Проверка работоспособности конфигурации — тестирование в программе «1С: Автоматическое тестирование конфигураций».
• Проверка на соответствие стандартам 1С, выполняемая в программе «1С: Автоматизированная проверка конфигураций».

Материалы для проверки передаются с помощью электронной почты, ftp или файлообменника.

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

Лучше 1 раз попробовать, чем 100 раз прочитать

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

Заполните форму — а всё остальное организуют наши специалисты.

Также можно позвонить по бесплатному номеру 8 (800) 77-51-256 либо написать письмо на Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript..

1С: Предпроизводственная проверка

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

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

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

Для выполнения проверки со стороны разработчика потребуется:

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

Состав тестов/стоимость/сроки	Полный состав тестов	Упрощенный состав тестов	Полный – упрощенный
Проверка сопроводительных файлов дистрибутива (основная поставка/обновление)	Да	Да	—
Проверка установки дистрибутива (основная поставка/обновление)	Да	Да	—
Проверка запуска рабочей базы (конфигуратор/предприятие)	Да	Да	—
Проверка запуска демобазы (конфигуратор/предприятие)	Да	Да	—
Проверка сопроводительных файлов каталога шаблона (основная поставка/обновление)	Да	Да	—
Сравнение конфигураций (демо – рабочая/ обновленная – основная)	Да	Да	—
Проверка свойств, общих сведений  о конфигурации	Да	Да	—
Проверка прав на интерактивное удаление	Да	Да	—
Проверка справки	Да	Да	—
Проверка обновления конфигурации предыдущего релиза (демобаза/рабочая база)	Да	Да	—
Проверка запуска обновленной конфигурации в режиме предприятия (демобаза/рабочая база)	Да	Да	—
Синтаксический контроль модулей с исключением ошибок, указанных в файле отсутствия ошибок	Да	—	Да
Проверка конфигурации с исключением ошибок, указанных в файле отсутствия ошибок	Да	—	Да
Проверка перепроведения документов с исключением ошибок, указанных в файле отсутствия ошибок	Да	—	Да
Проверка открытия/закрытия форм с исключением ошибок, указанных в файле отсутствия ошибок	Да	—	Да
Проверка в конфигурации параметров интернет-поддержки	Да	Да	—
Проверка заявленного функционала согласно СППР ОР/СР	Да	Да	—
Проверка файла «ЗакрытыеКоды_Название конфигурации в каталоге шаблонов. Номер релиза.xls»	Да	Да	—
Стоимость 1 итерации проверки	4 000 р.	3 000 р.	2 000 р.
Срок проверки	12 ч.	8 ч.	8 ч.

Дополнительно специалисты «1С-ИжТиСи» могут проконсультировать разработчиков по вопросам подготовки программных продуктов к выпуску, а также оказать помощь при передаче и публикации материалов в фирму «1С».

Проверка работоспособности конфигурации

Тестирование конфигурации 1С с помощью продукта «1С: Автоматическое тестирование конфигураций». Это инструмент для максимально полной проверки работоспособности конфигураций, разработанных на платформах «1С: Предприятие 8.2» и «1С: Предприятие 8.3».

Для выполнения проверки со стороны разработчика потребуется:

• DT-файл информационной базы с экземплярами объектов, которые необходимо протестировать, а также логин и пароль пользователя с правами администратора;
• CF-файл конфигурации, которую необходимо протестировать (например, чтобы найти ошибки, появившиеся в последнем релизе, необходимо предоставить CF-файл конфигурации последнего и предпоследнего релизов).

Состав тестов/стоимость/сроки	Полный состав тестов
Тест «Синтаксический контроль» (синтаксическая проверка конфигурации с возможностью сопоставления ошибок нескольких конфигураций, например: поиск ошибок, привнесенных в отраслевое решение)	Да
Тест «Проверка конфигурации» (проверка логической целостности конфигурации и поиск некорректных ссылок с возможностью сопоставления ошибок нескольких конфигураций)	Да
Тест «Вызов событий форм» (вызов всех событий форм)	Да
Тест «Сравнение движений документов» (выявление привнесенных в релиз ошибок)	Да
Стоимость 1 итерации проверки	4 000 р.
Срок проверки	5 раб. дней

Проверка на соответствие стандартам 1С

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

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

Для автоматизированной проверки конфигураций, разработанных на платформе «1С: Предприятие 8.3», на соответствие стандартам и иным требованиям технического характера используется программный продукт «1С: Автоматизированная проверка конфигураций».

Для выполнения проверки со стороны разработчика потребуется:

• Демо-база или DT-файл информационной базы, а также логин и пароль пользователя с правами администратора.

Состав тестов/стоимость/сроки	Полный состав тестов
Система стандартов	Да
Орфография	Да
1С:Совместимо	Да
Стоимость 1 итерации проверки	3 000 р.*
Срок проверки	8 ч.

* — стоимость в час. Трудозатраты на стандартную проверку не превышают 1 час. В случае если при начале проведения проверки возникают препятствия к ее запуску, связанные с конкретной конфигурацией (без дополнительных настроек и доработок проверка конфигурации не запускается) Исполнитель вправе отказать в предоставлении услуги. В случае если Заказчик хочет, чтобы проблема запуска была устранена силами Исполнителя, услуги по устранению проблемы запуска тарифицируются по ставке 3 000 руб. в час, количество часов выставляется по факту вложенных трудозатрат.