Как упорядочить код в 1С: практическое руководство для разработчика

Беспорядок в коде 1С проявляется постепенно: сначала в общем модуле появляется «лишняя» процедура, затем обработчики формы разрастаются до сотен строк, а через год никто уже не помнит, зачем нужна функция ПолучитьДанные2(). Упорядочить код — значит привести его к предсказуемой структуре, где каждый фрагмент лежит на своём месте, назван понятно и может быть изменён без страха сломать смежную логику.

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

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

Разберитесь, какой код где должен лежать

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

Общие модули стоит группировать по прикладным областям, а не по типу операций. Правильно: РаботаСНоменклатурой, ОбменСБанком. Неправильно: ОбщегоНазначения, Утилиты, Вспомогательные — такие модули неизбежно превращаются в свалку, куда попадает всё подряд.

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

Настройте общие модули по правилам

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

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

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

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

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

Переменные именуйте по содержимому, а не по типу: ТаблицаЗаказов вместо ТЗ1, ТекущийПользователь вместо ТекПольз. Однобуквенные и транслитерированные имена (Spisok, Kol) — верный признак кода, который через полгода не поймёт и сам автор.

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

Разбейте длинные процедуры

Процедура на 200–300 строк, в которой перемешаны проверки, запросы, циклы и формирование результата, — главный кандидат на упорядочивание. Признаки того, что метод пора делить: трудно придумать ему короткое имя, внутри есть блоки, отделённые пустыми строками и комментариями-заголовками, одни и те же фрагменты повторяются с небольшими вариациями.

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

1. 1
   Сделайте копию исходной процедуры или зафиксируйте версию в хранилище
2. 2
   Найдите логически цельный фрагмент (например, блок запроса) и вынесите его в новую функцию с параметрами
3. 3
   Замените фрагмент вызовом новой функции, выполните синтаксическую проверку модуля
4. 4
   Повторите для остальных блоков, после каждого шага проверяя компиляцию
5. 5
   Прогоните сценарий, который использует эту процедуру, и сравните результат с поведением до изменений

Не стремитесь переписать всё за один раз. Разумная тактика — «правило бойскаута»: каждый раз, когда вы дорабатываете процедуру по задаче, заодно приводите в порядок именно её. За несколько месяцев такой работы кодовая база заметно выравнивается без отдельного рискованного проекта «большого рефакторинга».

Устраните дублирование и мёртвый код

Скопированные фрагменты — скрытый источник ошибок: исправление вносится в одну копию и забывается в трёх других. Найдите дубли поиском характерных строк по всей конфигурации и замените копии вызовом одной процедуры общего модуля. Если копии слегка отличаются — выносите различия в параметры.

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

Используйте области и комментарии осмысленно

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

Комментарии должны объяснять «почему», а не «что». Комментарий // увеличиваем счётчик на 1 бесполезен, а // пропускаем первую строку — в файле заголовок колонок экономит время следующему разработчику. У каждой экспортной процедуры общего модуля полезно держать короткое описание назначения и параметров.

#Область ПрограммныйИнтерфейс

// Возвращает остаток товара на складе на дату.
//
// Параметры:
//   Номенклатура - СправочникСсылка.Номенклатура
//   Склад - СправочникСсылка.Склады
//   НаДату - Дата
//
// Возвращаемое значение:
//   Число - количество в базовой единице измерения.
//
Функция ОстатокТовараНаСкладе(Номенклатура, Склад, НаДату) Экспорт
	// ...
КонецФункции

#КонецОбласти

Проверяйте результат и закрепляйте порядок

Любое упорядочивание завершается проверкой. Минимум — синтаксический контроль модулей в конфигураторе (меню «Конфигурация — Проверка конфигурации») с проверкой всех режимов, включая тонкий и веб-клиент, если они используются. Затем — прогон сценариев, затронутых изменениями: проведение документов, формирование отчётов, обмены.

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

Частые вопросы