Что такое стандарты разработки и для чего они нужны
Большую часть времени программист 1С посвящает написанию кода. Это могут быть как доработки типовых решений фирмы 1С, так и разработка конфигураций с нуля. В результате работы получается “кодовая база”, которую нужно поддерживать, обновлять и со временем дорабатывать. Причем, в основном, эту работу выполняют разные программисты.
Стандарты разработки — это система рекомендаций и правил, применяемых в процессе разработки и направленных на:
- упрощение читаемости кода;
- улучшение “кодовой базы”;
- снижение трудозатрат при обновлении;
- ускорение последующих доработок.
Следование стандартам не всегда делает процесс написания кода быстрее и проще, однако качество выполненной работы помогает сократить трудозатраты программистов и заказчиков в будущем.
Получить консультацию по продуктам 1С вы можете -> здесь
Система стандартов и методик разработки конфигураций от 1С
Начать изучение стандартов разработки следует с официальных рекомендаций фирмы 1С. Эти правила основаны на огромном опыте разработки и внедрения, а также прошли проверку временем. Изучение всех стандартов и их интеграция в процесс разработки может занять длительное время. Однако некоторые правила достаточно просты, чтобы сразу начать их применять и оценить все преимущества разработки по стандартам.
Наименования объектов и методов
Правильные наименования объектов, а также процедур и функций упрощают разработку и поддержку решений за счет стандартизации и улучшения читаемости кода. Помимо этого, корректные наименования помогают избежать ошибок в конструкторе запросов и упростить процессы интеграции.
С полным списком правил именования объектов можно ознакомиться на ИТС. В рамках данной статьи подробнее разберем правила именования процедур и функций.
1. При выборе имени метода необходимо отталкиваться от терминов предметной области. Нужно стремиться к тому, чтобы суть метода была понятна без чтения его кода.
2. Имена функций следует образовывать на основе описания возвращаемого значения.
3. В именах процедур рекомендуется использовать глаголы в неопределенной форме.
С полным список правил и рекомендаций по именованию методов можно ознакомиться на ИТС.
Использование областей в модулях
Стандарт разделения кода модуля на области позволяет повысить читаемость кода и упростить внесение изменений разными разработчиками. Разберем основные разделы на примере общих модулей:
- “Программный интерфейс” содержит экспортные процедуры и функции, предназначенные для использования другими объектами конфигурации.
- “Служебный программный интерфейс” предназначен для модулей, которые являются частью некоторой функциональной подсистемы. В нем должны размещаться экспортные процедуры и функции, которые допустимо вызывать только из других функциональных подсистем этой же библиотеки.
- “Служебные процедуры и функции” содержит процедуры и функции, составляющие внутреннюю реализацию общего модуля.
Помимо основных областей, можно дополнительно создавать подразделы на основании общей тематики, что особенно актуально для больших модулей с множеством процедур и функций. Такой подход сокращает время, затрачиваемое на поиск нужных процедур и функций в процессе разработки.
С полным списком рекомендаций для всех модулей, а также шаблонами областей можно ознакомиться на ИТС.
Чтение отдельных реквизитов объекта
При получении значения одного реквизита объекта из базы данных нужно помнить, что обращение к реквизитам объекта через точку от ссылки приводит к загрузке объекта из базы целиком, вместе с его табличными частями. В случае объекта с множеством реквизитов и объемными табличными частями это может привести к проблемам с производительностью. Поэтому в таких случаях рекомендуется использовать запрос. Например:
Для конфигураций с использованием библиотеки стандартных подсистем можно использовать функции “ЗначенияРеквизитовОбъекта” или “ЗначениеРеквизитаОбъекта”.
Аналогичный пример с использованием функций БСП:
Многократное выполнение однотипных запросов
Вместо выполнения однотипного запроса в цикле, в целях оптимизации рекомендуется получить все данные одним запросом. Например, неправильно:
Правильно:
Однако есть исключения. Использование запроса в цикле допускается в следующих случаях:
- Значительное усложнение запроса для получения всех данных;
- Порционная обработка большого объема данных;
- Снижение производительности запроса.
Использование внутренних стандартов
Помимо стандартов, предложенных фирмой 1С, в каждой компании могут быть свои внутренние правила разработки. К ним также стоит отнестись серьезно, ведь это поможет привести “кодовую базу” к общему виду и упростить взаимодействие в команде. С примерами внутренних стандартов можно ознакомиться ниже.
Статьи и новости от наших экспертов 1С:ERP -> перейти в Телеграм
Переиспользование кода
При разработке следует учитывать возможность повторного использования кода из других модулей. Если похожий код должен вызываться из разных мест, продумайте вариант универсального решения в общем модуле или модуле объекта/менеджера.
В конфигурациях, использующих библиотеку стандартных подсистем, нужно по максимуму использовать готовые процедуры и функции. Это поможет существенно сократить время на разработку и снизить риск ошибок при разработке собственного решения.
Программное изменение форм
При добавлении новых элементов на форму типового объекта все изменения должны вноситься программно с использованием общего модуля “МодификацияКонфигурацииПереопределяемый” (или аналогичных).
Комментирование изменений
Любые изменения в коде, включая код в нетиповых модулях, должны сопровождаться комментарием по шаблону:
Последующие изменения внутри комментария, выполненные одним разработчиком в рамках одной задачи, дополнительно не комментируются.
Последствия отказа от стандартов разработки
Отказ от стандартов разработки 1С может повлечь к дополнительным рискам и затратам.
- Увеличение трудозатрат на поддержку: без стандартов код становится более трудным для понимания, что увеличивает время на сопровождение.
- Снижение качества “кодовой базы”: отказ от единого стандарта при разработке приведет к неравномерному качеству кода и использованию различных архитектурных решений.
- Сложности при масштабировании: использование рекомендаций фирмы 1С направлено на использование оптимальных решений. Отказ от стандартов может повлечь проблемы с оптимизацией при увеличении нагрузки.
- Ухудшение командной работы: использование разных подходов к разработке может привести к повторной реализации похожей функциональности, что снизит эффективность команды.
Заключение
Несмотря на трудозатраты по внедрению и использованию стандартов разработки, плюсы однозначно перевешивают минусы. Снижение рисков и будущих затрат делает использование стандартов важным аспектом успешной разработки на платформе 1С.
Если статья оказалась для вас полезной и интересной, поддержите нас своим лайком! 👍🏻 Ваше внимание помогает нам развиваться и создавать ещё больше ценного контента. Спасибо за вашу поддержку!