Общие рекомендации по внесению изменений в конфигурацию для последующего облегчения обновления.
Рекомендации по подписям, добавление реквизитов, модулей, форм, процедур…
Все мы не раз сталкивались с обновлением измененных конфигураций. Обычно это долгий и муторный процесс, и почти всегда что-то да теряется из функционала, который до этого старательно добавляли, особенно если это функционал добавляли не вы. Как с этим бороться? Как облегчить себе жизнь?
Вот несколько наработок и правил, которые в этом помогают:
1) Подписи.
Все мы обычно подписываемся так:
///Тима — Тима для примера, может быть вася петя инициалы итд
Но это не совсем верно: если в глобальном поиске набрать «Тима», то вылезет куча не нужных вещей, например «Функция дкПривестиМакетПечатнойФормы(ЭтотОбъект,Макет)». (Хотя можно искать и «/Тима»
поэтому лучше подписываться латинскими буквами!
Дальше нам надо, к примеру, изменить знак в строке)
Переменная = Переменная - 1; ///TIMA
Если мы подпишемся так, то это будет не очень ясно, а писать в комментарии, что конкретно изменил не всегда получается понятно другому человеку, поэтому лучше комментировать все строки, которые вы изменяете, а ниже уже писать свои:
И если вы изменяете целый блог то лучше еще вставить начало изменений и конец изменений.:
///Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///Tima -
Также если работает несколько человек над одной конфигурации, то перед именем в подписи вставьте что-то общее, например имя организации, для которой вы все это меняете:
///RogaAndKopita Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///RogaAndKopita Tima -
2) Подписки на события!
Ну конечно же во-первых и во-вторых используйте Подписки на события.
Порядок выполнения подписки на событие не регламентирован, пишите код исходя из этого.
3) Добавление реквизитов, модулей, форм итд
Все новые объекты конфигурации добавляете с префиксом (например, «Dop_» или «RogaAndKopita_» или «Tima_»).
То же самое касается и новых функций или процедур.
4) Добавление новых процедур
Все новыее процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Старайтесь как можно больше процедур и функций помещать в СВОЙ общий модуль, вы себе этим здорово облегчите жизнь.
Если вы забудете, что вносили изменения и затрете свои или чужие наработки, то гораздо легче найти место, куда вставлять вызов процедуры, чем восстанавливать всю процедуру заново.
5) Изменения в формах.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Первый способ.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Процедура ДопПриОткрытии()
///Сюда вставляем что хотим до
Выполнить(допПолучитьСтароеДействиеФормы(ЭтаФорма, "ПриОткрытии"));
///Сюда тоже можно вставлять
КонецПроцедуры
Второй способ.
Позаимствовал у компании Рарус обработку реквизитов: в модуле формы во все требуемые процедуры пишем строчку:
///Если Обрабатываем ТабЧасть:
ОбработкаРеквизита("ИмяТабЧасти.ИмяРекизита", ЭлементыФормы.ИмяТабЧасти.ТекущаяСтрока, ЭтаФорма);
///Если обрабатываем реквизит формы или событие:
ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
А в модуле документа делаем:
Функция ОбработкаРеквизита(Имя,ТекСтрока=Неопределено,ЭтаФорма=Неопределено,ДопПараметры=Неопределено) Экспорт
Если имя = "ИмяРекизита" тогда
ИначеЕсли имя = "ИмяРекизитаДругого" тогда
//А если надо вызвать обработку другого реквизита при выполнении кода это делается легко:
возврат ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
Иначе
//// А тут можно сделать вызов такой же функции в общем модуле для изменения общих реквизитов (например ставка НДС)
Возврат ДопОбработкаРеквизита(Имя,ТекСтрока,ЭтаФорма,ДопПараметры);
КонецЕсли;
КонецФункции
6) Изменение самой формы
Если нужно изменить саму форму, например добавить реквизит или еще что-то, можно использовать декомпилятор форм:
А код из декомпилятора вставлять в процедуру ПриОткрытии (конечно с учетом 5-го пункта)
А вот если требуется сильно переделать всю форму, то советую создавать новую форму, тогда при обновлении всего лишь переопределится форма по умолчанию, а все ваши изменения не потеряются.
Вот собственно и все приемы, которые я знаю. Если знаете еще способы, то пишите, обязательно их добавлю.
1. Если меняется одна строка, то лучше писать комментарий в той же строке или перед ней.
Со временем таких изменений будет несколько и код может выглядеть как елка — всё зеленое от почти бессмысленных комментариев.
Да и причину писать надо. Бывает на одну строку кода пишешь 2-3 строки комментария.
Переменная = Переменная — 1; ///RogaAndKopita Tima +++ вместо «+» будет «-» потому что <причина действий> 230813
2. Все новые процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Частично согласен. Но я бы советовал не один модуль, а несколько. Разделить их, во-первых, по направлениям/участкам работы. Во-вторых, на клиентскую и серверную часть.
И не стоит скидывать со счетов модули менеджеров — очень полезная вещь, особенно, если функция или процедура работает только с одним видом объекта конфигурации.
3. Могу предложить еще вариант «триггеров» — некий справочник, в котором хранится код 1С, вызываемый в тех или иных случаях — динамическое изменение кода, универсальность встраивания.
Подписки хороши, если мы что-то делаем «по факту» и с целым объектом. А если нам надо в форме документа проверять реквизит на какие-то условия?
Если условий 5-10 штук, они меняются раз в месяц, да еще зависят от второй буквы девичьей фамилии матери отца соседа снизу пользователя?
Вот тут и пригодится такой внешний код — вызов займет 1-2 строки, при встраивании в типовую конфигурацию удобнее обновлять несколько строк, чем «километры» кода.
4. Для изменяемых объектов типовой конфигурации можно завести отдельную подсистему «ВрезкаВТиповую» и включать объекты в случае их изменения — это позволит в случае «врезок» либо исправления ошибок до выхода новой версии типовой фиксировать измененные объекты чтобы отслеживать их при обновлении.
Главное обновляй конфу поставщика нормально и все твои врезки будут видны и понятны ибо никакие комментарии не помогут понять, что же цензура сделали в этой конфе, где версия cf 3.0.2, а версия поставщика 1.0.1 …
А такие комментарии нафиг не нужны, т.к. они больше похожи на написанное на заборе «Сдесь был Вася!» , «Выпуск 1986г.»…
(105) Gazza, «завести отдельную подсистему «ВрезкаВТиповую»» — я пришел к выводу о том, лучше делать следующую иерархию подсистем — первая МоиПодсистемы, и ей подчиненные МоиДобавленныеОбъекты, ОбъектыТиповойИзмененные,ИсправленныеОбъектыТиповойСОшибками.
В первую добавляем свои объекты — удобнее просматривать что добавлено, вторая подсистема позволяет контролировать а не слетели ли доработки, а третья контролировать глюки типовой которые в следующем релизе могут быть исправлены.
(105) Gazza, не согласен. Когда есть список заявок и в комментах писать не вася, а №заявки такой. то потом можно: а) узнать зачем вносились изменения и с какими объектами они связаны; б) проще искать изменения;
//—> I.F. Проведение будущей датой
Процедура ОбработчикИзмененияДаты(Данные)
Если Данные=»ДокументОбъект.Дата» ИЛИ Данные=»» Тогда
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
//<— I.F. Проведение будущей датой
//…
////////////////////////////////////////////////////////////////////////////////
// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ
//…
//—> I.F. Проведение будущей датой
ПодключитьОбработчикИзмененияДанных(«Дата»,»ОбработчикИзмененияДаты»);
//<— I.F. Проведение будущей датой
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#
Прайс-лист с артикулом в отдельной колонке
1. Если меняется одна строка, то лучше писать комментарий в той же строке или перед ней.
Со временем таких изменений будет несколько и код может выглядеть как елка — всё зеленое от почти бессмысленных комментариев.
Да и причину писать надо. Бывает на одну строку кода пишешь 2-3 строки комментария.
Переменная = Переменная — 1; ///RogaAndKopita Tima +++ вместо «+» будет «-» потому что <причина действий> 230813
2. Все новые процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Частично согласен. Но я бы советовал не один модуль, а несколько. Разделить их, во-первых, по направлениям/участкам работы. Во-вторых, на клиентскую и серверную часть.
И не стоит скидывать со счетов модули менеджеров — очень полезная вещь, особенно, если функция или процедура работает только с одним видом объекта конфигурации.
3. Могу предложить еще вариант «триггеров» — некий справочник, в котором хранится код 1С, вызываемый в тех или иных случаях — динамическое изменение кода, универсальность встраивания.
Подписки хороши, если мы что-то делаем «по факту» и с целым объектом. А если нам надо в форме документа проверять реквизит на какие-то условия?
Если условий 5-10 штук, они меняются раз в месяц, да еще зависят от второй буквы девичьей фамилии матери отца соседа снизу пользователя?
Вот тут и пригодится такой внешний код — вызов займет 1-2 строки, при встраивании в типовую конфигурацию удобнее обновлять несколько строк, чем «километры» кода.
4. Для изменяемых объектов типовой конфигурации можно завести отдельную подсистему «ВрезкаВТиповую» и включать объекты в случае их изменения — это позволит в случае «врезок» либо исправления ошибок до выхода новой версии типовой фиксировать измененные объекты чтобы отслеживать их при обновлении.
1 пункт, если в типовые модули делать минимум изменений то как елка код не будет выглядеть, а в доп модулях комментировать все не обязательно.
2 пункт да, видно надо было расширить в статье это.
3 пункт получается аналог внешнего модуля, просто изменения можно внедрять не залезая в конфигуратор. Такой вариант тоже имеет право на жизнь.
(0) Шаблоны для вставки комментариев рулят
Шаблон общий
Шаблон для проекта
а в английских версиях БСП писать ///ТИМА ?
Главное обновляй конфу поставщика нормально и все твои врезки будут видны и понятны ибо никакие комментарии не помогут понять, что же
цензурасделали в этой конфе, где версия cf 3.0.2, а версия поставщика 1.0.1 …А такие комментарии нафиг не нужны, т.к. они больше похожи на написанное на заборе «Сдесь был Вася!» , «Выпуск 1986г.»…
Добавлю, что в начале модуля мы ставим еще и информацию о заявке по которой вносились изменения. Например:
// 1.01 10.09.2013 Иванов И.И. по заявке 235 добавил вариант заполнения контрагента
и уже в модуле
// 1.01 Добавлено, начало
….
// 1.01 Добавлено, конец
(105) Gazza, «завести отдельную подсистему «ВрезкаВТиповую»» — я пришел к выводу о том, лучше делать следующую иерархию подсистем — первая МоиПодсистемы, и ей подчиненные МоиДобавленныеОбъекты, ОбъектыТиповойИзмененные,ИсправленныеОбъектыТиповойСОшибками.
В первую добавляем свои объекты — удобнее просматривать что добавлено, вторая подсистема позволяет контролировать а не слетели ли доработки, а третья контролировать глюки типовой которые в следующем релизе могут быть исправлены.
(105) Gazza, не согласен. Когда есть список заявок и в комментах писать не вася, а №заявки такой. то потом можно: а) узнать зачем вносились изменения и с какими объектами они связаны; б) проще искать изменения;
Правильно отмечено! «обновлять конфигурацию поставщика» — обязательно.
Показать
Сакральные знания)) хотя для новичков может и полезно