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

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

Часто проект не можна назвати цілком успішним, якщо клієнт не залишився в організації-інтеграторі на підтримку. І якщо дотримуватися строгих правил зміни типових конфігурацій, то витративши зовсім незначний час на етапі розробки, можна заощадити багато-багато годин і нервів в майбутньому на постійному оновленні зміненої конфігурації. І навпаки, грубе, «байдуже» ставлення до оформлення коду, вибір більш швидких і простих, а не правильних способів реалізації завдань можуть перетворити оновлення вийшла конфігурації в справжнє пекло для підтримки. Надалі це виллється в величезний годинник поновлення, різку завантаженість розробників в звітний період, велику кількість помилок після поновлення, невдоволення клієнтів і т. Д.

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

0. Зміст списку правил розробки:

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

Якщо модифікуються типову конфігурацію передбачається оновлювати у міру випуску нових релізів, то розробникам слід завжди пам’ятати про це і вживати заходів щодо полегшення оновлення. Слід завжди вибирати ті способи вирішення завдань, які забезпечать більш просте оновлення конфігурації в майбутньому, навіть якщо вони трохи складніше в реалізації. Звичайно, тільки за умови, що у більш зручного для поновлення способу немає серйозних недоліків в області продуктивності, зрозумілості коду і т. Д.

2. Коментування змін коду:

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

// ++ VION 20.07.2016 0001234 Доопрацювання на старті
// – VION 20.07.2016

де

  • – початок блоку
  • – кінець блоку
  • – ім’я (або нік) розробника
  • 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

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

Якщо ж закриває коментар поставити на наступному рядку:

Те при «попроцедурном порівнянні» даний коментар буде вважатися описом наступної по тексту процедури, яка буде вважатися зміненої.

3. Додавання об’єктів верхнього рівня

імена об’єктів верхнього рівня, створюваних в конфігурації, обов’язково повинні починатися з префікса вашої компанії або окремого префікса проекту. Як правило, він складається з двох-трьох великих літер і підкреслення, наприклад АБ_. Відповідно, створювані об’єкти будуть називатися АБ_НовийСправочнік, АБ_НовийРегістрСведеній, АБ_НовийДокумент і т.д.

Синоніми (видимі користувачеві імена) доданих об’єктів верхнього рівня повинні починатися з префікса, укладеного в круглі дужки: (АБ). В результаті ці об’єкти будуть візуально виділятися в списках і згруповано розташовуватися в їх початку (що полегшує і тестування, і використання).

У коментарі створюваного об’єкта слід вказати ім’я розробника, дату і номер завдання, по аналогії з додається коду, але без знаків «++». Це забезпечить прив’язку об’єкта конфігурації до задачі, відшукуємо глобальним пошуком.

приклад: Створити довідник «Проекти».

дії розробника: В конфігурації створюється наступний довідник:

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

4. Додавання підлеглих об’єктів

Спосіб додавання реквізитів об’єктів конфігурації залежить від того, в який об’єкт конфігурації додається реквізит: в об’єкт конфігурації, створений постачальником типового рішення (т. Е. Об’єкт на підтримку) або об’єкта, доданого в рамках поточного проекту (т. Е. Вже має префікс) .

4.1 Додавання підлеглих об’єктів в типові об’єкти конфігурації

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

У коментарі створюваного об’єкта слід вказати ім’я розробника, дату і номер завдання, по аналогії з. Це забезпечить прив’язку об’єкта конфігурації до задачі, відшукуємо глобальним пошуком.

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

дії розробника: В конфігурації створюється наступний реквізит:

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

4.2 Додавання підлеглих об’єктів в об’єкти, додані в рамках проекту

Підлеглі об’єкти, що додаються в об’єкти верхнього рівня додані в конфігурацію в рамках проекту, т. Е. Вже містять в імені префікс, додаються без префікса. Синоніми таких підлеглих об’єктів створюються також без префікса.

У коментарі створюваного об’єкта слід вказати ім’я розробника, дату і номер завдання, по аналогії з. Це забезпечить прив’язку об’єкта конфігурації до задачі, відшукуємо глобальним пошуком. Коментар можна не вказувати, якщо реквізити створюються в рамках тієї ж завдання, що і сам об’єкт верхнього рівня.

приклад: Створити реквізит «Відповідальний» у довідника «(АБ) Проекти».

дії розробника: Якщо завдання відмінна від тієї, в якій створювався довідник «(АБ) Проекти», то в конфігурації створюється наступний реквізит:

  • Ім’я: Відповідальний
  • Синонім: Відповідальний
  • Коментар: // VION 20.07.2016 000456

5. Додавання визначених елементів

При додаванні визначених елементів довідників, планів видів характеристик і планів рахунків слід використовувати ті ж правила, що і при додаванні підлеглих об’єктів (табличних частин, реквізитів) в об’єкти верхнього рівня.

5.1 Додавання визначених елементів в типові об’єкти конфігурації

Зумовлені елементи для типових об’єктів конфігурації обов’язково додаються з префіксом. Найменування задається без префікса.

приклад: У план рахунків «Госпрозрахунковий» додати зумовлений рахунок 10.15 – Бланки суворої звітності.

дії розробника: Додати наступний зумовлений рахунок:

  • Ім’я: АБ_БланкіСрогойОтчетності
  • Код: 10.15
  • Найменування: Бланки суворої звітності

Якщо необхідно перейменувати зумовлений елемент типового об’єкта конфігурації (наприклад, рахунок), слід залишити сам об’єкт без змін, а перейменування виконати програмно в спеціальній.

5.2 Додавання визначених елементів в об’єкти, додані в рамках проекту

В об’єкти конфігурації додані в рамках проекту, т. Е. Вже містять в своєму імені префікс, зумовлені елементи додаються без префікса в імені та найменування.

6. Використання загальних модулів і їх сувора структура

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

  • АБ_ОбщегоНазначенія (Клієнт, сервер, зовнішнє з’єднання) – для розміщення звичайних процедур і функцій.
  • АБ_Серверний (Тільки сервер) – для процедур і функцій, які обов’язково повинні виконуватися в середовищі сервера.
  • АБ_Глобальний – для процедур і функцій, виклик яких стандартним способом (через ім’я модуля і точку) незручний.
  • АБ_Прівілегірованний – для процедур і функцій, які завжди потрібно виконувати під повними правами.
  • АБ_ПовторноеІспользованіе – для кешування повертаються значень деяких функцій.

В окремі загальні модулі можна виносити код функціональних блоків великого обсягу, в цьому випадку спрощується налагодження такого коду при використанні сховища конфігурації. В інших випадках, розробнику слід переконатися в наявності відповідного загального модуля перед додаванням нового модуля в конфігурацію.

7. Використання підписок і їх сувора структура

Для обробки різних подій, пов’язаних з об’єктами типової конфігурації, слід використовувати механізм підписок замість внесення модифікації в модулі самих об’єктів, якщо є така можливість.

Для кожної події може бути не більше однієї передплати (Як об’єкта метаданих), обробник якої і пов’язаний з ним код повинні розташовуватися в окремому загальному модулі (Для підвищення паралельності роботи розробників зі сховищем). Ім’я підписки і ім’я загального модуля повинні бути однакові і відповідати оброблюваного події. Як джерело підписки вказуються Усе потенційно можливі для обробки об’єкти (все довідники, всі документи і т. п.).

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

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

дії розробника:

1. Створити підписку «АБ_ДокументиОбработкаПроведенія» (якщо така підписка не була створена раніше), як джерело вказати всі документи, подія – «ОбработкаПроведенія».

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

3. У модулі створити експортну процедуру «ОбработкаПроведенія». Вибрати цю процедуру в якості обробника створеної раніше підписки. У процедурі, в залежності від типу документа, викликаються необхідні обробники.

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

8. Редагування форм

8.1 Редагування форм типових об’єктів

Якщо зміна типової форми (як звичайної, так і керованої) невелике (наприклад, винести на форму кілька нових реквізитів), то виконувати таку зміну слід повністю програмно. Т. е. Зміни вносяться тільки в модуль форми, а сама форма в конфігураторі залишається незмінною. Деяким розробникам такий метод редагування форм спочатку може здатися досить трудомістким. Однак, маючи достатній досвід програмного зміни форм, на додавання одного елемента буде йти не більше 3-5 хвилин. Витрачений час багаторазово окупається при оновленні типової конфігурації.

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

дії розробника: У обробнику форми «ПріСозданііНаСервере» додати процедуру «ДоработатьФормуПрограммно ()». У даній процедурі додати потрібний елемент в елементи форми.

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

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

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

Де на ім’я форми можна викликати необхідну процедуру з програмною доопрацюванням форми.

Якщо ж на форму планується додати велика кількість елементів або табличних частин, то можливо і ручна зміна форми. В цьому випадку рекомендується створити на формі окрему вкладку, і вже на ній розміщувати всі необхідні елементи. Це значно полегшить подальше оновлення форми.

8.2 Редагування форм об’єктів, доданих в рамках проекту

Форми об’єктів, доданих в рамках проекту (т. Е. Мають у своїй назві префікс) редагуються звичайним способом.

9. Принципи роботи з ролями

Типові ролі завжди слід залишати незмінними (якщо це можливо). Це потрібно для полегшення поновлення зміненої конфігурації з нових релізів, тому що порівняння і відновлення ролей є складним і кропіткими процесом.

Права на додаються в конфігурацію об’єкти слід призначати в нових, створюваних для цієї мети ролях.

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

10. Зовнішні звіти та обробки

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

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

Розробникам рекомендується активно використовувати механізм Додаткових звітів і обробок, коли це можливо.

Ссылка на основную публикацию