Правила доработки типовых конфигураций 1С для облегчения их дальнейшего обновления (часть 1)

Logo_1c_8_Razradotka

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

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

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

0. Оглавление списка правил разработки:

  1. Концепция минимизации «разрушений» типовой конфигурации
  2. Комментирование изменений кода
    1. Вставка кода
    2. Удаление кода
    3. Изменение существующего кода
    4. Добавление процедур и функций в модуле
  3. Добавление объектов верхнего уровня
  4. Добавление подчиненных объектов
    1. В типовые объекты конфигурации
    2. В объекты, добавленных в рамках проекта
  5. Добавление предопределенных элементов
    1. В типовые объекты конфигурации
    2. В объекты, добавленных в рамках проекта
  6. Использование общих модулей и их строгая структура
  7. Использование подписок и их строгая структура
  8. Редактирование форм
    1. Типовых объектов
    2. Объектов, добавленных в рамках проекта
  9. Принципы работы с ролями
  10. Внешние отчеты и обработки

1. Концепция минимизации «разрушений» типовой конфигурации

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

2. Комментирование изменений кода:

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

//++ VION 20.07.2016 0001234 Доработка на старте
//-- VION 20.07.2016

Где

  • //++ — начало блока
  • //— — конец блока
  • VION — имя (или ник) разработчика
  • 0001234 — номер задачи по трекеру, ставится только в открывающем комментарии, чтобы в результаты глобального поиска по номеру задачи каждое изменение кода попадало только один раз
  • Доработка на старте — произвольный комментарий, используется при необходимости, но если номер задачи отсутствует, то краткий пояснительный текст обязателен

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

Обрамляющие комментарии выравниваются по левому краю редактируемого блока кода. Способы использования комментирования изменений продемонстрированы на примерах ниже:

2.1 Вставка кода

Пример:

Процедура ПриОткрытии()
    Если ЭтоНовый() Тогда
        ЗаполнитьПоляПоУмолчанию();
    КонецЕсли;
    НастроитьЭлементыФормы();
    //++ VION 20.07.2016 0001234
    НастроитьДополнительныеЭлементы();
    //-- VION 20.07.2016
    УстановитьВидимостьПолей();
КонецПроцедуры

2.2 Удаление кода

Пример:

Процедура ПриОткрытии()
    //++ VION 20.07.2016 0001234
    //Если ЭтоНовый() Тогда
    //    ЗаполнитьПоляПоУмолчанию();
    //КонецЕсли;
    НастроитьДополнительныеЭлементы();
    //-- VION 20.07.2016
    УстановитьВидимостьПолей();
КонецПроцедуры

2.3 Изменение существующего кода

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

Пример:

Процедура ПриОткрытии()
    Если ЭтоНовый() Тогда
        //++ VION 20.07.2016 000123
        //ЗаполнитьПоляПоУмолчанию();
        НастройкаЗаполненияПолей = ПолучитьНастройкуЗаполненияПолей();
        ЗаполнитьПоляПоУмолчаниюРасширенная(НастройкаЗаполненияПолей);
        //-- VION 20.07.2016
    КонецЕсли;
    НастроитьЭлементыФормы();
    УстановитьВидимостьПолей();
КонецПроцедуры

2.4 Добавление процедур и функций в модуле

Для добавляемых процедур и функций, а также для объявления переменных модуля типовых объектов действуют дополнительные правила оформления комментариев:

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

Пример:

//++ VION 20.07.2016 000123
Перем мНастройкаЗаполненияПолей; //-- VION 20.07.2016

//++ VION 20.07.2016 000123
Процедура ДоработатьФормуПрограммно()
    ...
    ...
КонецПроцедуры //-- VION 20.07.2016

//++ VION 20.07.2016 000123
Процедура ДатаОтгрузкиОбработкаВыбора()
    ...
    ...
КонецПроцедуры //-- VION 20.07.2016

Данное правило позволяет легко переносить изменения в модуле в «попроцедурном сравнении» конфигураций.

pravila-razrabotki-tipovyx-konfiguracij_002

Если же закрывающий комментарий поставить на следующей строке:

pravila-razrabotki-tipovyx-konfiguracij_003

То при «попроцедурном сравнении» данный комментарий будет признан описанием следующей по тексту процедуры, которая будет считаться измененной.

pravila-razrabotki-tipovyx-konfiguracij_001

3. Добавление объектов верхнего уровня

Имена объектов верхнего уровня, создаваемых в конфигурации, обязательно должны начинаться с префикса вашей компании или отдельного префикса проекта. Как правило, он состоит из двух-трех заглавных букв и подчёркивания, например АБ_. Соответственно, создаваемые объекты будут называться АБ_НовыйСправочник, АБ_НовыйРегистрСведений, АБ_НовыйДокумент и т. д.

Синонимы (видимые пользователю имена) добавленных объектов верхнего уровня должны начинаться с префикса, заключённого в круглые скобки: (АБ). В результате эти объекты будут визуально выделяться в списках и сгруппировано располагаться в их начале (что облегчает и тестирование, и использование).

pravila-razrabotki-tipovyx-konfiguracij_005

В комментарии создаваемого объекта следует указать имя разработчика, дату и номер задачи, по аналогии с заголовочным комментарием добавляемого кода, но без знаков «++». Это обеспечит привязку объекта конфигурации к задаче, отыскиваемую глобальным поиском.

Пример: Создать справочник «Проекты».

Действия разработчика: в конфигурации создается следующий справочник:

  • Имя: АБ_Проекты
  • Синоним: (АБ) Проекты
  • Комментарий: // VION 20.07.2016 000123

pravila-razrabotki-tipovyx-konfiguracij_004

4. Добавление подчиненных объектов

Способ добавления реквизитов объектов конфигурации зависит от того, в какой объект конфигурации добавляется реквизит: в объект конфигурации, созданный поставщиком типового решения (т. е. объект на поддержке) или объекта, добавленного в рамках текущего проекта (т. е. уже имеющего префикс).

4.1 Добавление подчиненных объектов в типовые объекты конфигурации

Подчинённые объекты, добавляемые в существующие (типовые) объекты конфигурации, должны снабжаться префиксами: АБ_ДополнительныйРеквизит, АБ_НоваяТабличнаяЧасть, АБ_ФормаНастроекПользователя, АБ_МакетСпециальнаяНакладная. Но при этом синонимы таких подчинённых объектов создаются без префикса.

В комментарии создаваемого объекта следует указать имя разработчика, дату и номер задачи, по аналогии с оформлением созданного модуля. Это обеспечит привязку объекта конфигурации к задаче, отыскиваемую глобальным поиском.

Пример: Создать реквизит «Проект» документа «Авансовый платеж».

Действия разработчика: в конфигурации создается следующий реквизит:

  • Имя: АБ_Проект
  • Синоним: Проект
  • Комментарий: // VION 20.07.2016 000123

pravila-razrabotki-tipovyx-konfiguracij_006

4.2 Добавление подчиненных объектов в объекты, добавленные в рамках проекта

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

В комментарии создаваемого объекта следует указать имя разработчика, дату и номер задачи, по аналогии с оформлением созданного модуля. Это обеспечит привязку объекта конфигурации к задаче, отыскиваемую глобальным поиском. Комментарий можно не указывать, если реквизиты создаются в рамках той же задачи, что и сам объект верхнего уровня.

Пример: Создать реквизит «Ответственный» у справочника «(АБ) Проекты».

Действия разработчика: Если задача отличная от той, в которой создавался справочник «(АБ) Проекты», то в конфигурации создается следующий реквизит:

  • Имя: Ответственный
  • Синоним: Ответственный
  • Комментарий: // VION 20.07.2016 000456

pravila-razrabotki-tipovyx-konfiguracij_007

5. Добавление предопределенных элементов

При добавлении предопределенных элементов справочников, планов видов характеристик и планов счетов следует использовать те же правила, что и при добавлении подчиненных объектов (табличных частей, реквизитов) в объекты верхнего уровня.

5.1 Добавление предопределенных элементов в типовые объекты конфигурации

Предопределенные элементы для типовых объектов конфигурации обязательно добавляются с префиксом. Наименование задается без префикса.

Пример: В план счетов «Хозрасчетный» добавить предопределенный счет 10.15 — Бланки строгой отчетности.

Действия разработчика: Добавить следующий предопределенный счет:

  • Имя: АБ_БланкиСрогойОтчетности
  • Код: 10.15
  • Наименование: Бланки строгой отчетности

pravila-razrabotki-tipovyx-konfiguracij_016

Если необходимо переименовать предопределенный элемент типового объекта конфигурации (например, счет), следует оставить сам объект без изменений, а переименование выполнить программно в специальной обработке инициализации.

5.2 Добавление предопределенных элементов в объекты, добавленные в рамках проекта

В объекты конфигурации добавленные в рамках проекта, т. е. уже содержащие в своем имени префикс, предопределенные элементы добавляются без префикса в имени и наименовании.

6. Использование общих модулей и их строгая структура

Неоднократно используемые в конфигурации процедуры и функции, обработчики подписок и регламентных заданий размещаются в общих модулях. Для этих целей следует добавлять собственные модули, добавленные по правилам добавления объектов верхнего уровня, оставляя типовые модули неизменными. При разработке будут полезны следующие общие модули («АБ_» — префикс):

  • АБ_ОбщегоНазначения (клиент, сервер, внешнее соединение) — для размещения обычных процедур и функций.
  • АБ_Серверный (только сервер) — для процедур и функций, которые обязательно должны исполняться в среде сервера.
  • АБ_Глобальный — для процедур и функций, вызов которых стандартным способом (через имя модуля и точку) неудобен.
  • АБ_Привилегированный — для процедур и функций, которые всегда нужно исполнять под полными правами.
  • АБ_ПовторноеИспользование — для кэширования возвращаемых значений некоторых функций.

pravila-razrabotki-tipovyx-konfiguracij_008

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

7. Использование подписок и их строгая структура

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

Для каждого события может быть не более одной подписки (как объекта метаданных), обработчик которой и связанный с ним код должны размешаться в отдельном общем модуле (для повышения параллельности работы разработчиков с хранилищем). Имя подписки и имя общего модуля должны быть одинаковы и соответствовать обрабатываемому событию. В качестве источника подписки указываются все потенциально возможные для обработки объекты (все справочники, все документы и т. п.).

Процедура-обработчик подписки должна содержать вызовы подпроцедур, выполняющих нужные действия. Обращение к ним осуществляется в зависимости от типа источника, а также в нужной последовательности. Комментирование в модуле подписки при добавлении кода по новым задачам осуществляется по общим правилам.

Пример: При проведении документа «Авансовый платеж», делать записи в регистр накопления «(АБ) Затраты по проектам».

Действия разработчика:

1. Создать подписку «АБ_ДокументыОбработкаПроведения» (если такая подписка не была создана раннее), в качестве источника указать все документы, событие — «ОбработкаПроведения».

pravila-razrabotki-tipovyx-konfiguracij_009

2. Создать общий серверный модуль «АБ_ДокументыОбработкаПроведения».

pravila-razrabotki-tipovyx-konfiguracij_010

3.  В модуле создать экспортную процедуру «ОбработкаПроведения». Выбрать данную процедуру в качестве обработчика созданной ранее подписки. В процедуре, в зависимости от типа документа, вызываются необходимые обработчики.

pravila-razrabotki-tipovyx-konfiguracij_011

4. Модуль документа «Авансовый платеж» должен остаться без изменений.

8. Редактирование форм

8.1 Редактирование форм типовых объектов

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

Пример: На основную форму документа «Авансовый платеж», добавить реквизит «(АБ) Проект».

Действия разработчика: В обработчике формы «ПриСозданииНаСервере» добавить процедуру «ДоработатьФормуПрограммно()». В данной процедуре добавить нужный элемент в элементы формы.

pravila-razrabotki-tipovyx-konfiguracij_012

Возможно создание отдельного модуля, в котором будут содержаться все необходимые процедуры и функции для изменения типовых форм.

pravila-razrabotki-tipovyx-konfiguracij_013

В типовых конфигурациях на базе БСП 2, уже есть специальный функционал для данных целей:

pravila-razrabotki-tipovyx-konfiguracij_017

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

pravila-razrabotki-tipovyx-konfiguracij_018

Где по имени формы можно вызвать необходимую процедуру с программной доработкой формы.

pravila-razrabotki-tipovyx-konfiguracij_019

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

8.2 Редактирование форм объектов, добавленных в рамках проекта

Формы объектов, добавленных в рамках проекта (т. е. имеющие в своем названии префикс) редактируются обычным способом.

9. Принципы работы с ролями

Типовые роли всегда следует оставлять неизменными (если это возможно). Это нужно для облегчения обновления изменённой конфигурации из новых релизов, потому что сравнение и восстановление ролей является сложным и кропотливыми процессом.

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

Запреты на доступ к данным, разрешенным типовыми ролями, следует реализовывать программным способом, пока это возможно. И только когда подобный запрет будет очень сложно реализовать программно (либо такое решение будет ненадёжным), допустимо модифицировать типовые роли. Изменения типовых ролей должны быть минимально необходимыми и документированными. Например, если необходимо изменить текст ограничений доступа в роли (RLS), то согласно общим правилам, следует закомментировать весь типовой код, после чего добавить код с необходимыми изменениями.

pravila-razrabotki-tipovyx-konfiguracij_014

10. Внешние отчеты и обработки

Большинство доработок в системе может быть выполнено с помощью механизма Дополнительных отчетов и обработок.

pravila-razrabotki-tipovyx-konfiguracij_015

В конфигурациях на основе БСП 2 (ERP, УТ 11, БП 3.0, ЗУП 3.0 и т. д) этот механизм значительно расширен. С его помощью без изменения конфигурации возможно создавать внешние отчеты и обработки (с размещением команды запуска в командном интерфейсе и возможностью настройки доступа различным пользователям), обработки заполнения документа, обработки создания документа на основании, дополнительные печатные формы и др.

Разработчикам рекомендуется активно использовать механизм Дополнительных отчетов и обработок, когда это возможно.

Продолжение статьи

Помогла ли вам данная статья?
Да, спасибо, помогла.
Немного помогла.
Совсем не помогла.
Не то, что я искал(а).
Смотреть результаты
Запись опубликована в рубрике Разработка в 1С с метками . Добавьте в закладки постоянную ссылку.


One Response to Правила доработки типовых конфигураций 1С для облегчения их дальнейшего обновления (часть 1)

  1. Спасибо, отличная идея!!!!!!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *