Что такое идеальный код на 1С и как его написать

← На главную

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

Критерии идеального кода в экосистеме 1С

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

Читаемость и простота. Хороший код кажется банальным. Он написан так, что при открытии модуля через несколько лет логика остается понятной без дополнительных комментариев.
Масштабируемость. Идеальный код позволяет внести изменения в одном месте (например, в процедуре инициализации), после чего эти изменения автоматически наследуются во всей связанной цепочке процессов.
Отсутствие избыточности. Как отмечают эксперты, «идеальный код — это сферический конь в вакууме», но на практике это код, который не хочется переписать сразу после прочтения.
Соответствие стандартам БСП. Использование Библиотеки стандартных подсистем сегодня является де-факто стандартом качества.

Разбор практического примера: Управление лицевыми счетами

Рассмотрим пример кода, который встречается в типовом решении «Зарплата и Управление Персоналом» (редакция 2.5). Задача заключается в обеспечении уникальности основного лицевого счета сотрудника. Проанализируем, как реализована проверка и установка флага ОсновнойЗарплатныйПроект в модуле набора записей регистра сведений.


ТаблицаНабораЗаписей = ЭтотОбъект.Выгрузить();
ОтборОсновнойЗарплатныйПроект = Новый Структура;
ОтборОсновнойЗарплатныйПроект.Вставить("ОсновнойЗарплатныйПроект", Истина);
МассивСтрокНабораЗаписей = ТаблицаНабораЗаписей.НайтиСтроки(ОтборОсновнойЗарплатныйПроект);

Если МассивСтрокНабораЗаписей.Количество() = 0 Тогда
    Возврат;
КонецЕсли;

СписокФизЛицНабора = Новый СписокЗначений;
Для каждого СтрокаНабораЗаписей Из МассивСтрокНабораЗаписей Цикл    
    Если Не СписокФизЛицНабора.НайтиПоЗначению(СтрокаНабораЗаписей.ФизЛицо) = Неопределено Тогда
        СтрокаНабораЗаписей.ОсновнойЗарплатныйПроект = Ложь;
        Продолжить;
    КонецЕсли;
    СписокФизЛицНабора.Добавить(СтрокаНабораЗаписей.ФизЛицо);
КонецЦикла;

ЭтотОбъект.Загрузить(ТаблицаНабораЗаписей);

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

Использование построителя запроса для сложных отборов

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


ПостроительЗапроса = Новый ПостроительЗапроса;
ПостроительЗапроса.Текст = 
"ВЫБРАТЬ
|    ЛицевыеСчетаРаботниковОрганизации.Организация,
|    ЛицевыеСчетаРаботниковОрганизации.Банк,
|    ЛицевыеСчетаРаботниковОрганизации.ФизЛицо
|ПОМЕСТИТЬ ВТ_ЛицевыеСчетаСОтборомНабораЗаписей
|ИЗ
|    РегистрСведений.ЛицевыеСчетаРаботниковОрганизации КАК ЛицевыеСчетаРаботниковОрганизации
|ГДЕ
|    ЛицевыеСчетаРаботниковОрганизации.ФизЛицо В(&СписокФизЛиц)
|    И ЛицевыеСчетаРаботниковОрганизации.ОсновнойЗарплатныйПроект";

ПостроительЗапроса.ЗаполнитьНастройки();
// Динамическое заполнение отбора из структуры
ЗаполнитьОтборИзСтруктуры(ПостроительЗапроса.Отбор, ПолучитьСтруктуруОтбора(Отбор));

Этот подход примечателен тем, что разработчик не пишет громоздкие условия «ГДЕ» вручную, а делегирует это платформенному механизму ПостроительЗапроса. Это делает код более гибким к изменениям метаданных (например, при добавлении новых измерений в регистр).

Культура тестирования и Assert-ы

Важной составляющей «прекрасного» кода является его надежность. Проанализируем ситуацию: часто ли мы проверяем входные данные на Неопределено или деление на ноль? В профессиональной разработке принято использовать механизмы проверки утверждений (Asserts).

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

Пример правильной проверки (защитное программирование):


Процедура РассчитатьСумму(Цена, Количество)
    // Проверка входных параметров
    Если Цена < 0 Или Количество < 0 Тогда
        ВызватьИсключение "Параметры расчета не могут быть отрицательными!";
    КонецЕсли;
    
    // Основная логика
    Сумма = Цена * Количество;
КонецПроцедуры

Где искать эталонный код?

Если вы хотите увидеть примеры действительно качественной архитектуры, стоит обратить внимание на следующие компоненты:

Конвертация данных (КД 2.0). Несмотря на почтенный возраст, механизмы сопоставления объектов и использования рекурсии в правилах обмена реализованы там на высочайшем уровне.
Библиотека стандартных подсистем (БСП). Это «золотой стандарт» современного 1С-программирования. Разделение на программные интерфейсы и переопределяемые модули позволяет создавать гибкие системы.
Инструменты разработчика. Проекты типа «Универсальный обмен данными XML» демонстрируют виртуозное владение объектной моделью 1С.

Методические рекомендации по написанию чистого кода

Подведем итог нашему анализу и сформулируем правила, которые приблизят ваш код к идеалу:

Именуйте переменные осмысленно. Вместо ТекСтр пишите СтрокаЛицевогоСчета. Это избавляет от необходимости писать комментарии к каждой строке.
Минимизируйте запросы в циклах. Это базовое правило производительности. Всегда старайтесь выгрузить данные в массив или таблицу и передать их в один запрос.
Используйте типизацию. Несмотря на то что 1С — язык с динамической типизацией, старайтесь проектировать функции так, чтобы они принимали и возвращали предсказуемые типы данных.
Разделяйте логику и интерфейс. Модуль формы должен содержать только логику визуализации. Вся бизнес-логика должна быть вынесена в общие модули или модули менеджеров.

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