Рассмотрим частую проблему, с которой сталкивается каждый 1С-разработчик: как правильно выделить свои изменения в типовой конфигурации или в чужом коде, чтобы при последующих обновлениях или командной разработке не возникло проблем. Выясним причину появления различных шаблонов и проанализируем, какие практики считаются устаревшими, а какие — современным стандартом.
Разберем по шагам, как исторически складывались правила оформления доработок. Многие программисты используют ручные вставки, чтобы визуально отделить свой код от кода поставщика. Это делается для того, чтобы специалист знал, что это делал он, или чтобы быстро вспомнить суть изменений в будущем.
Самый общепринятый и распространенный образец выглядит следующим образом:
// +++ [Дата] [Описание доработки] [Автор/Компания]
// Здесь идет добавленный код
// ---
Посмотрим на пример из практики, когда программист вносит изменения в существующую процедуру. Шаблон может приобретать более расширенный вид:
// +++ 15.10.2023 Иванов И.И. (ООО "Ромашка")
// Добавлено условие для обхода ошибки деления на ноль по задаче #4532
Процедура РассчитатьСумму()
// ... логика ...
КонецПроцедуры
// --- 15.10.2023 Иванов И.И.
Для упрощения жизни «потомкам» при ручном слиянии кода рекомендуется использовать парные маркеры. Такой подход позволяет избежать ситуаций, когда при обновлении конфигурации программист случайно удаляет закрывающую скобку или конец условия, так как границы блока четко обозначены.
Проанализируем ситуацию с точки зрения официальных стандартов разработки. В «Стандартах и методиках разработки» фирмы «1С» прямо указывается, что избыточное комментирование кода не приветствуется. Сам код должен быть самодокументируемым: если вы используете понятные имена переменных и процедур, то дополнительные пояснения часто не нужны.
Однако при доработке именно типовых конфигураций рекомендуется использовать специфические метки. Они помогают механизму сравнения и объединения наглядно показывать границы изменений. Главное правило — не превращать модуль в бесконечное полотно из комментариев.
Профессиональные разработчики редко пишут шаблоны вручную, так как это отнимает время и приводит к опечаткам. Разберем инструменты, которые ускоряют этот процесс:
.st). Вы можете настроить горячие клавиши так, чтобы при их нажатии вставлялся готовый блок с текущей датой и вашим логином из системы.<FIX_001>, <ADD_001>, <DEL_001>. Это позволит вам мгновенно найти все свои исправления, добавления или удаления через полнотекстовый поиск по конфигурации.Если над проектом работает большая команда, то требования к шаблонам ужесточаются. Если модуль был значительно переработан, в самом начале текста модуля добавляется блок «История изменений». Посмотрим, как это выглядит:
// ==============================================================================
// ИСТОРИЯ ИЗМЕНЕНИЙ
// ==============================================================================
// Версия | Дата | Автор | Описание задачи
// ------------------------------------------------------------------------------
// 1.0.1 | 10.10.2023 | Петров П.П. | #1233 Оптимизация запроса в функции ПолучитьДанные
// 1.0.2 | 12.10.2023 | Сидоров С.С. | #1250 Добавлена обработка новых статусов
// ==============================================================================
Здесь важно описывать суть изменений с точки зрения бизнеса (зачем это сделано), а не дублировать код словами (что сделано).
Теперь рассмотрим самый правильный и современный подход. Как отмечают опытные специалисты, правильно — интегрировать систему контроля версий с системой контроля заданий. Все подробности, причины доработок и "шаблоны" должны описываться именно там.
С переходом на 1C:Enterprise Development Tool (EDT) и системы контроля версий (например, Git) необходимость в ручных комментариях с датой и автором внутри кода стремительно снижается. Инструмент Git Blame позволяет увидеть автора, дату изменения и номер коммита для каждой конкретной строки кода без визуального засорения самого модуля.
В современной корпоративной разработке золотым правилом считается оставлять в коде только номер задачи из системы управления проектами (Jira, Redmine, СППР):
// Задача #7789
Если УсловиеВыполнено Тогда
// новый код
КонецЕсли;
Таким образом, если потомкам нужно будет разобраться, зачем был написан этот код, они просто возьмут номер задания, зайдут в систему контроля заданий и увидят там полную постановку задачи, обсуждения, прикрепленные файлы и исходные требования.
В завершение обсудим качество самого кода. Общепринятые правила в 1С такие же, как и в других языках программирования: если ваш код понятен новичку — он хороший. Если даже опытный специалист не может понять, что делает алгоритм и где искать его связи по разным местам конфигурации, это плохой код.
Также в профессиональной среде считается дурным тоном оставлять в комментариях оценочные суждения, ругательства или жалобы на предыдущего разработчика. Если вы применяете нестандартный подход, опишите причину техническим языком:
// Вынужденное решение из-за ошибки платформы при работе с временными таблицами.
// Обходной путь реализован в рамках задачи #5541.
Подводя итоги, мы видим, что «правильный» шаблон зависит от технологического стека вашей команды. Если вы работаете в конфигураторе — используйте аккуратные текстовые маркеры и шаблоны .st. Если вы перешли на EDT — доверьте историю изменений системе Git, оставляя в коде лишь аккуратные ссылки на номера задач в баг-трекере.