Когда мы, как разработчики и специалисты по 1С, сталкиваемся с необходимостью провести анализ качества типовой конфигурации с помощью Автоматической проверки конфигурации (АПК), мы часто видим ошеломляющее количество ошибок. Это может вызвать недоумение: как же так, ведь это типовое решение, находящееся на поддержке, и создано самой фирмой 1С? Давайте разберем, почему такая ситуация возникает и как 1С подходит к этому вопросу.
Представим ситуацию: мы запускаем АПК на практически типовой конфигурации 1С:Бухгалтерия Предприятия 3.0 (БП3) и получаем более 250 тысяч ошибок. Одна из таких ошибок может касаться, например, реквизита табличной части Билеты документа АвансовыйОтчет, а именно реквизита СуммаНДС. АПК может указать на нарушение правил наименования, требуя более полного синонима или соответствия строгим стандартам, несмотря на то, что «НДС» является общеупотребительной аббревиатурой.
Такая ситуация вызывает закономерный вопрос: неужели разработчики 1С не знают о своих же требованиях, или есть какое-то иное объяснение этому феномену? Мы выясним, что это не так просто, и за кажущимся хаосом скрывается продуманная система управления качеством и обратной совместимостью.
Автоматическая проверка конфигурации — это мощный инструмент, содержащий обширный набор правил. Эти правила охватывают множество аспектов разработки, таких как:
НДС или МСФО).Эти правила зачастую очень строгие, и даже небольшие отклонения, которые не влияют на функциональность системы, могут быть помечены как ошибки. Однако, в процессе реальной разработки типовых решений, особенно таких масштабных, как БП3 или Библиотека стандартных подсистем (БСП), возникают факторы, которые заставляют отступать от этих строгих правил.
Один из ключевых моментов, который мы должны понимать, это то, что разработчики 1С прекрасно знают о своих требованиях и активно используют механизмы исключений для своих типовых библиотек и конфигураций. Это не означает, что они игнорируют качество, а скорее, что они управляют им, учитывая множество факторов.
Для каждой типовой библиотеки, например, для Библиотеки Стандартных Подсистем (БСП), существуют специальные файлы исключений. Мы можем найти их в шаблонах поставки конфигурации по пути \ExtFiles\Особенности конфигурации (АПК).xml. Эти файлы содержат списки ошибок, которые АПК должна игнорировать при проверке данной конкретной библиотеки или конфигурации. В таких файлах ошибки могут быть помечены как:
Эти файлы позволяют АПК не сообщать о заведомых "нарушениях" в коде 1С, которые были сделаны осознанно или оставлены по объективным причинам. Когда мы запускаем АПК, она, по идее, должна учитывать эти файлы исключений. Если АПК продолжает выводить эти ошибки, это может быть связано с тем, что механизм исключений настроен не до конца или АПК запускается в режиме, который не учитывает эти особенности.
Вернемся к примеру с реквизитом СуммаНДС. Замечания по наименованиям часто возникают из-за того, что АПК не всегда способна адекватно оценить контекст использования сокращений или терминов. Хотя «НДС» является общеупотребительной аббревиатурой в бухгалтерском учете, система АПК может требовать явного указания таких исключений или более полного синонима в соответствии со своими строгими правилами наименования.
Мы должны понимать, что АПК — это автоматический инструмент. Он не обладает человеческим интеллектом для понимания всех нюансов предметной области. Поэтому, если для некоторого сокращения, которое в нашей прикладной области считается общепринятым, АПК выдает ошибку, это не всегда означает, что это критическая проблема. Скорее всего, это означает, что АПК не "обучена" распознавать это сокращение как допустимое без явных указаний или исключений.
С развитием платформы 1С:Предприятие и самих конфигураций, количество проверок в АПК постоянно увеличивается. Добавляются новые правила, улучшаются существующие алгоритмы анализа кода. Это, в свою очередь, может приводить к выявлению большего числа потенциальных "ошибок", даже в старых, проверенных частях кода, которые ранее не вызывали нареканий. С течением времени, обновления типовых конфигураций и новые версии платформы могут вносить изменения, которые, в свою очередь, могут приводить к появлению новых сообщений от АПК.
Мы, как разработчики, должны учитывать, что новые версии АПК могут быть более строгими или иметь расширенный набор проверок, которые ранее не применялись к существующему коду.
Особенности конфигурации (АПК).xml, поставляемые вместе с типовыми конфигурациями и библиотеками. Это даст нам понимание того, какие ошибки 1С считает допустимыми или неисправимыми.В целом, большое количество ошибок АПК в типовых конфигурациях не всегда свидетельствует о критических проблемах, требующих немедленного исправления. Скорее, это отражает строгость правил проверки, эволюцию стандартов и необходимость учета специфических исключений, разработанных самой фирмой 1С для поддержания стабильности и функциональности своих продуктов. Мы должны использовать АПК как инструмент для обучения и повышения качества собственного кода, а не как безапелляционный приговор типовым решениям.