- Что такое стандарты разработки и для чего они нужны
- Система стандартов и методик разработки конфигураций от 1С
- Наименования объектов и методов
- Использование областей в модулях
- Чтение отдельных реквизитов объекта
- Многократное выполнение однотипных запросов
- Использование внутренних стандартов
- Переиспользование кода
- Программное изменение форм
- Комментирование изменений
- Последствия отказа от стандартов разработки
- Заключение
Что такое стандарты разработки и для чего они нужны
Большую часть времени программист 1С посвящает написанию кода. Это могут быть как доработки типовых решений фирмы 1С, так и разработка конфигураций с нуля. В результате работы получается “кодовая база”, которую нужно поддерживать, обновлять и со временем дорабатывать. Причем, в основном, эту работу выполняют разные программисты.

Стандарты разработки — это система рекомендаций и правил, применяемых в процессе разработки и направленных на:
- упрощение читаемости кода;
- улучшение “кодовой базы”;
- снижение трудозатрат при обновлении;
- ускорение последующих доработок.
Следование стандартам не всегда делает процесс написания кода быстрее и проще, однако качество выполненной работы помогает сократить трудозатраты программистов и заказчиков в будущем.
Система стандартов и методик разработки конфигураций от 1С
Начать изучение стандартов разработки следует с официальных рекомендаций фирмы 1С. Эти правила основаны на огромном опыте разработки и внедрения, а также прошли проверку временем. Изучение всех стандартов и их интеграция в процесс разработки может занять длительное время. Однако некоторые правила достаточно просты, чтобы сразу начать их применять и оценить все преимущества разработки по стандартам.
Наименования объектов и методов
Правильные наименования объектов, а также процедур и функций упрощают разработку и поддержку решений за счет стандартизации и улучшения читаемости кода. Помимо этого, корректные наименования помогают избежать ошибок в конструкторе запросов и упростить процессы интеграции.
С полным списком правил именования объектов можно ознакомиться на ИТС. В рамках данной статьи подробнее разберем правила именования процедур и функций.
1. При выборе имени метода необходимо отталкиваться от терминов предметной области. Нужно стремиться к тому, чтобы суть метода была понятна без чтения его кода.
Функция ПолучитьРеквизитФормыПоПути(Форма, ПутьРеквизита)
Функция РазделительПакетаЗапросов()
2. Имена функций следует образовывать на основе описания возвращаемого значения.
Функция МассивШтрихкодов(ДанныеШтрихкодов)
Функция ТекстЗапросаДанныеЗаполненияНакладной()
3. В именах процедур рекомендуется использовать глаголы в неопределенной форме.
Процедура ИнициализироватьУсловияПродаж()
Процедура ЗаполнитьДокументПоОтбору(Знач ДанныеЗаполнения)
С полным список правил и рекомендаций по именованию методов можно ознакомиться на ИТС.
Использование областей в модулях
Стандарт разделения кода модуля на области позволяет повысить читаемость кода и упростить внесение изменений разными разработчиками. Разберем основные разделы на примере общих модулей:
- “Программный интерфейс” содержит экспортные процедуры и функции, предназначенные для использования другими объектами конфигурации.
- “Служебный программный интерфейс” предназначен для модулей, которые являются частью некоторой функциональной подсистемы. В нем должны размещаться экспортные процедуры и функции, которые допустимо вызывать только из других функциональных подсистем этой же библиотеки.
- “Служебные процедуры и функции” содержит процедуры и функции, составляющие внутреннюю реализацию общего модуля.
#Область ПрограммныйИнтерфейс
// Код процедур и функций
#КонецОбласти
#Область СлужебныйПрограммныйИнтерфейс
// Код процедур и функций
#КонецОбласти
#Область СлужебныеПроцедурыИФункции
// Код процедур и функций
#КонецОбласти
Помимо основных областей, можно дополнительно создавать подразделы на основании общей тематики, что особенно актуально для больших модулей с множеством процедур и функций. Такой подход сокращает время, затрачиваемое на поиск нужных процедур и функций в процессе разработки.
С полным списком рекомендаций для всех модулей, а также шаблонами областей можно ознакомиться на ИТС.
Чтение отдельных реквизитов объекта
При получении значения одного реквизита объекта из базы данных нужно помнить, что обращение к реквизитам объекта через точку от ссылки приводит к загрузке объекта из базы целиком, вместе с его табличными частями. В случае объекта с множеством реквизитов и объемными табличными частями это может привести к проблемам с производительностью. Поэтому в таких случаях рекомендуется использовать запрос. Например:
Функция ОрганизацияЗаказаКлиента(Документ)
Результат = Справочники.Организации.ПустаяСсылка();
Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Ссылка", Документ);
Запрос.Текст =
"ВЫБРАТЬ
| ЗаказКлиента.Организация КАК Организация
|ИЗ
| Документ.ЗаказКлиента КАК ЗаказКлиента
|ГДЕ
| ЗаказКлиента.Ссылка = &Ссылка";
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Если Выборка.Следующий() Тогда
Результат = Выборка.Организация;
КонецЕсли;
Возврат Результат;
КонецФункции
Для конфигураций с использованием библиотеки стандартных подсистем можно использовать функции “ЗначенияРеквизитовОбъекта” или “ЗначениеРеквизитаОбъекта”.

Аналогичный пример с использованием функций БСП:
Организация = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Документ, "Организация");
Многократное выполнение однотипных запросов
Вместо выполнения однотипного запроса в цикле, в целях оптимизации рекомендуется получить все данные одним запросом. Например, неправильно:
Процедура ДополнитьТоварамиРеализаций(Товары, Реализации)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
| СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
|ГДЕ
| РеализацияТоваровУслугТовары.Ссылка = &Реализация
|
|СГРУППИРОВАТЬ ПО
| РеализацияТоваровУслугТовары.Номенклатура";
Для Каждого Реализация Из Реализации Цикл
Запрос.УстановитьПараметр("Реализация", Реализация);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
НоваяСтрока = Товары.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрока, Выборка);
КонецЦикла;
КонецЦикла;
КонецПроцедуры
Правильно:
Процедура ДополнитьТоварамиРеализаций(Товары, Реализации)
Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Реализации", Реализации);
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
| СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
|ГДЕ
| РеализацияТоваровУслугТовары.Ссылка В (&Реализации)
|
|СГРУППИРОВАТЬ ПО
| РеализацияТоваровУслугТовары.Номенклатура";
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
НоваяСтрока = Товары.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрока, Выборка);
КонецЦикла;
КонецПроцедуры
Однако есть исключения. Использование запроса в цикле допускается в следующих случаях:
- Значительное усложнение запроса для получения всех данных;
- Порционная обработка большого объема данных;
- Снижение производительности запроса.
Использование внутренних стандартов
Помимо стандартов, предложенных фирмой 1С, в каждой компании могут быть свои внутренние правила разработки. К ним также стоит отнестись серьезно, ведь это поможет привести “кодовую базу” к общему виду и упростить взаимодействие в команде. С примерами внутренних стандартов можно ознакомиться ниже.
Переиспользование кода
При разработке следует учитывать возможность повторного использования кода из других модулей. Если похожий код должен вызываться из разных мест, продумайте вариант универсального решения в общем модуле или модуле объекта/менеджера.
В конфигурациях, использующих библиотеку стандартных подсистем, нужно по максимуму использовать готовые процедуры и функции. Это поможет существенно сократить время на разработку и снизить риск ошибок при разработке собственного решения.
Программное изменение форм
При добавлении новых элементов на форму типового объекта все изменения должны вноситься программно с использованием общего модуля “МодификацияКонфигурацииПереопределяемый” (или аналогичных).
Комментирование изменений
Любые изменения в коде, включая код в нетиповых модулях, должны сопровождаться комментарием по шаблону:
//++ Добавлено
//<Название компании>, <Фамилия разработчика>, <Номер задачи>
//--
Последующие изменения внутри комментария, выполненные одним разработчиком в рамках одной задачи, дополнительно не комментируются.
Последствия отказа от стандартов разработки
Отказ от стандартов разработки 1С может повлечь к дополнительным рискам и затратам.
- Увеличение трудозатрат на поддержку: без стандартов код становится более трудным для понимания, что увеличивает время на сопровождение.
- Снижение качества “кодовой базы”: отказ от единого стандарта при разработке приведет к неравномерному качеству кода и использованию различных архитектурных решений.
- Сложности при масштабировании: использование рекомендаций фирмы 1С направлено на использование оптимальных решений. Отказ от стандартов может повлечь проблемы с оптимизацией при увеличении нагрузки.
- Ухудшение командной работы: использование разных подходов к разработке может привести к повторной реализации похожей функциональности, что снизит эффективность команды.

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