Регламент внесения изменений в типовые конфигурации

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

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

Так же следует напоминать разработчикам что при внесении изменений в конфигурацию следует использовать Систему стандартов разработки приложенную к данной публикации

1. Цель
Обозначить правила внесения изменений в случае доработок конфигураций.
2. Границы
Данная инструкция рекомендуется к исполнению всем сотрудникам НАЗВАНИЕОРГАНИЗАЦИИ
3. Ответственные
Программисты
4. Терминология
Система стандартов – система стандартов расположенная на диске ИТС.
Руководство по стилю – Руководство по стилю для типовых конфигураций на платформе 1С:Предприятие 8.2 "Управляемое приложение", расположена на диске ИТС.

5. Процедура

5.1. Добавление подсистем для регистрации изменений
Кто делает: Программист
Периодичность: Перед первым внесением изменений в конфигурации
Как делает:
5.1.1. Перед началом внесения изменений в конфигурации необходимо создать две дополнительные подсистемы:
Имя Синоним Дополнительные параметры ПРЕФИКС_Добавлено Объекты добавленные компанией НАЗВАНИЕОРГАНИЗАЦИИ Включать в командный интерфейс – Ложь ПРЕФИКС_Изменено Объекты измененные компанией НАЗВАНИЕОРГАНИЗАЦИИ Включать в командный интерфейс - Ложь
5.2. Добавление новых объектов метаданных
Кто делает: Программист
Как делает:
5.2.1. Перед созданием новых объектов нужно убедиться, что данная функциональность не решается типовыми средствами. В случае если данная функциональность решается типовыми средствами, изменения вносить не треуется.
5.2.2. В случае если типовой функционал не решает задачи программист создает объект метаданных, у созданного объекта имя начинается с префикса «ПРЕФИКС_», т.е. если нужно создать справочник Договоры контрагентов, то создается объект с именем: «ПРЕФИКС_ДоговорыКонтрагентов», синоним «Договоры контрагентов». При создании имени метаданных следует руководствоваться Системой стандартов п. 1.3.2. В этом случае программисты, которые в дальнейшем будут обновлять или изменять конфигурацию сразу смогут понять, что этот объект создали сотрудники НАЗВАНИЕОРГАНИЗАЦИИ и он не типовой.
5.2.3. Созданный объект метаданных нужно добавить в состав подсистемы «ПРЕФИКС_Добавлено».
5.3. Добавление реквизитов в объекты метаданных
Кто делает: Программист
Как делает:
5.3.1. Перед внесением дополнительных реквизитов конфигурации следует определить, возможно ли решить задачу с использованием добавления свойств объектов. Большинство задач можно решить с использованием данного механизма.
5.3.2. В случае если дорабатывается типовой объект метаданных (содержится в конфигурации поставщика), новый реквизит создается с префиксом «ПРЕФИКС_», т.е. если создается реквизит для справочника «Контрагенты», имя реквизита «ПРЕФИКС_Резидент», «Резидент». При именовании переменных следует руководствоваться Системой стандартов разработки п.4.1.5.
5.3.3. В случае если дорабатывается объект с префиксом «ПРЕФИКС_», т.е. объект метаданных был создан компанией НАЗВАНИЕОРГАНИЗАЦИИ, то в названии не следует использовать префикс ПРЕФИКС. Т.е. если нужно добавить реквизит «Используется», в справочник «ПРЕФИКС_Сертификаты», то добавляется реквизит с именем «Испольуется», синоним «Используется».
5.4. Изменение формы метаданных
Кто делает: Программист
Как делает:
5.4.1. В случае внесения изменений в типовую форму разработчику необходимо комментировать все свои изменения. В случае размещения нового реквизита на форме необходимо в модуле формы в самом начале расположить следующий код:
//ПРЕФИКС_(Фамилия)
//Добавлен реквизит (ИмяРеквизита), вкладка (название вкладки)
//_ПРЕФИКС
Т.е. в случае добавления на форму реквизита Резидент следует написать следующий комментарий:
//ПРЕФИКС_ФАМИЛИЯРАЗРАБОТЧИКА
//Добавлен реквизит Резидент, вкладка Дополнительно
//_ПРЕФИКС
5.4.2. В случае внесения изменений в форму созданную сотрудником компании НАЗВАНИЕОРГАНИЗАЦИИ, комментирование добавления элементов на форму делать не нужно.
5.4.3. В случае внесения изменений в код следует действовать в соответствии со следующим шаблоном.
//ПРЕФИКС_(Фамилия) Причина внесения изменений
//Исходный фрагмент кода
Фрагмент кода
//_ПРЕФИКС
Т.е. в случае если нужно изменить процедуру:

&НаКлиенте
Процедура Подобрать(Команда)

ВыбратьПодобратьПользователей(Истина);

КонецПроцедуры

То изменение будет выглядеть следующим образом:

&НаКлиенте
Процедура Подобрать(Команда)
//ПРЕФИКС_ФАМИЛИЯРАЗРАБОТЧИКА Изменяю процедуру подбора пользователей
// ВыбратьПодобратьПользователей(Истина);
ХХХ_ВыбратьПользователей();
//_ПРЕФИКС
КонецПроцедуры

5.5. Название переменных используемых при разработке
Кто делает: Программист
Как делает:
5.5.1. При внесении изменений в типовые модули переменные следует начинать с префикса «ПРЕФИКС_» т.е.
ПРЕФИКС_ТипЦенПоУмолчанию = Ложь //Тип цены по умолчанию
5.5.2. При внесении изменений в модули объектов, созданных компанией НАЗВАНИЕОРГАНИЗАЦИИ использование префикса не требуется.
5.5.3. Не рекомендуется использование имен переменных содержащих 1,2 или 3 буквы, т.е. А, Б, СЧ, Ном. Рекомендуется называть имена переменных так, чтобы сторонний разработчик в любом моменте встречи данной переменной понимал для чего она используется. Пример переменной СчетчикЦикла, ТекущийКонтрагент и т.п. Более подробно сказано в Стандартах разработки п.4.1.5.
5.6. Внесение изменений в события ОбработкаПроведения, ПередЗаписью и т.п.
Кто делает: Программист
Как делает:
5.6.1. В случае внесения изменений в процедуру Обработка проведения, перед записью и т.п. рекомендуется использовать механизм «Подписки на событие».
Т.е. в случае если нужно внести изменения в процедуру ОбработкаПроведения документа «Реализация товаров и услуг» следует создать подписку на событие, и описать алгоритм дополнительного проведения в общем модуле. Правила образования имен подписок на событие описана в Системе стандартов разработки п.1.3.2.