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

Немного покритикую

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

2) Если использовать сторонние программы для сравнения (я использую P4, он вроде как бесплатен для небольших команд) то быстро понимаешь, что зря не пользовался ими раньше при обновлении. Обновление модулей становится проще в 10 раз. И тут всплывает ньюанс. Такие программы сравнивают построчно, а не попроцедурно, и если что то было закомментировано, а в поставке добавили пробел - получили двойное изменение. Поэтому я предпочитаю по максимуму код от типовой не трогать, а решать только добавлением новых строчек - возврат, окружать Если Ложь Тогда итп

3) Для префиксации очень удобным оказался префикс "_" и "*" для синонимов. Они коротки и они выводят новые объекты вверх при сортировке, а обычно новые объекты нужны чаще, чем типовые. Для разработки коробочного решения такая префиксация не подходит, конечно.

4) Предопределенные элементы стоит добавлять только в те объекты, где их до этого не было, иначе если с новой типовой придет новый предопределенный объект, будет весело в любом случае. Тут ждем 8.3.11. Если все таки пришлось изменить предопределенные, то оставляю комментарий в корневом объекте, чтоб при сравнении объединении было видно и 1. что набор предопределенных изменений конфликтует 2. комментарий к объекту был изменен

5) Не понимаю этого фанатизма в использовании подписки для изменения логики в одном документе. В случае обновления если использовать п.2 проблем не возникает вообще, а вот убить кучу времени на выяснение логики работы документа при проведении, когда часть вынесена в подписки - это вообще запросто

6) Типовые роли лучше вообще не трогать. Сколько раз менял, столько раз имел проблемы. Если и менять, то прям в комментарии к объекту писать что именно изменено. РЛС в типовых не менял ни разу, видимо изза того, что я так и не смог раскурить что происходит в БСП или в документообороте.

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

8) Про справочник предопределенных значений хорошая идея, утащу к себе. У нас есть похожий механизм под кодовым названием "Экспериментальные функции". Если есть старый алгоритм чего то и мы разработали новый, но не очень в нем уверены, то старый не удаляем, а переключаем с помощью значения в предопределенном элементе в справочнике, типа так Если Справочники.ЭкспФункции.ИспользоватьНовыйАлгоритм.Включена Тогда НовыйАлгоритм() Иначе СтарыйАлгоритм() КонецЕсли

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

9) Чтобы научить программиста дорабатывать конфу так, чтоб легче было обновлять его следует сперва заставить выполнить обновление, чтоб он на все возможные проблемы понатыкался, а уже потом давать правила

Номер версии во внешних обработках\отчетах делаем по формату гг.мм.дд, 17.07.19

Расширениями не пользуетесь? До сих пор не могу для себя решить если в них польза. Были как положительные так и отрицательные примеры.

Кстати обновление готовите через cf или свою поставку?

Спасибо. Статья очень полезная, почерпнул некоторые полезности для себя. Проголосовал за доклад. В дополнение звездану статью!

Про БСП обновил знания - спасибо

Спасибо за статью. Всё структурировано и понятно. Как раз собирался что-то подобное писать для наших стажеров и наткнулся на эту публикацию. Забираю.

Cпасибо. Очень интересно. Можете привести код функции ВТ() для вычисления временных таблиц, которая описана в статье?

У меня вопрос к автору. В статье вы пишете о справочнике с предопределенными элементами. А чем он лучше обычных констант?

спасибо, много взял для себя

Откройте для себя отложенную отладку запросов и компоновки и получайте полное удовлетворение https://www.youtube.com/watch?v=hiw_aYVOvFc

По большей части согласен. Могу добавить "отсебятины":
1. часто вместо добавления реквизитов или табличных частей справочников и документов выгодным оказывается удобнее добавить регистр сведений, связанный через измерения с основным объектом, а в ресурсах хранящий необходимую информацию.
2. типовые объекты, куда не успели вмешаться, держим "под замком". Это одновременно индикатор и защита от случайных правок из разряда "лишний пробел"
3. В шаблонах кода очень удобно разместить собственный комментарий. Результат - при нажатии Ctrl + пробел в пустом месте в одной из верхних строк прелагается к вставке личная метка с текущей датой.
4. Касательно нетиповых участков - по возможности используем параметризированные запросы вместо склейки из строк. Сохранение возможности открыть запрос конструктором - небольшой бонус, позволяющий быстро отформатировать исправленный руками запрос и заодно проверить синтаксис (как известно, неправильный запрос конструктором не открывается). Комментирование внутри запроса достаточно бесполезно, т.к. исчезает при вызове конструктора, поэтому проще размещать тексты запросов в отдельных функциях, а перед правкой создавать копию всей функции с видоизмененным именем.
5. Громоздкие функции и процедуры удобнее дробить на мелкие, чем читать все это как сплошной текст.
6. Выигрышь в быстродействии на 5-10% за счет запутывания разрастания и усложнения кода пользователи не оценят. Но большинство оценивает разработку/доработки в короткий срок. Если Вы видите, что схожие подзадачи возникают с завидной регулярностью, чаще всего проще потратить полдня на универсальную функцию или механизм, закрывающие их все разом.
Например, однажды написав и вызвая в своих разработках функцию "ПреобразоватьТаблицуВДерево" скорее всего вы сможете выиграть больше времени по сравнению с описанием этого процесса в каждой отдельно взятой задаче.

После советов с "авторским комментарием" перестал читать. Как заколебали такие правила, потом умрёшь отучать разработчиков писать авторский комментарий и июзать Blame View.

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

Спасибо. Очень полезно.

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

Идея с процедурой ВТ() полезная, я до такого не додумался.

На мой ИМХО самоя крутая вещь при разработке это расширения, ко всему можно привязаться не редактируя модули и формы.
Еще с начала года как 8.3.9 появилась, снял на свой страх и риск с БП 3.0 совместимость с 8.3.8 и вперед.Единственный минут они нормально работают только начиная с 8.3.9. Если режим совместимости меньше то приходится по старинке...

Если эти источники для Вас не по существу, то без комментариев.

Объемная статья с картинками и видео-приложением, отражающая определенный, систематизированный подход к обновлению конфигураций. Автору безусловный плюс. И большое спасибо всем, кто высказал свое мнение в комментариях. Много интересного.

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

Все так. Единственное для новых объектов или реквизитов делаем не префиксы, а суффиксы. так не надо помнить это наш объект при кодировании или типовой. На Вашем примере "Проекты_ФТО". Попробуйте и Вам захочется переименовать все что вы делали.

Эти правила плюсанул бы лет 5 назад. Сейчас же это уже атавизм.
Как тут уже писали, git blame покажет кто когда и зачем писал каждую строку. Даже у кода поставщика вы увидите какая строка в каком из ваших обновлений обновилась.

Если типовой код нужно поменять на ваш — меняйте, не нужно оставлять старый! Нужно посмотреть что было раньше? Посмотрите историю в git. В 1С — сравните с конфигурацией поставщика. При обновлении 99,9% таких правок модулей пройдёт автоматически при помощи инструмента типа KDiff3. Попроцедурное в 1С вам не поможет в случае изменения названия процедуры, а инструмент справится. То же касается и обработок событий проведения и т. п.

Кстати говоря, в конфигурациях на основе УТ11, ERP там за формирование движений отвечает много вспомогательных процедур в модуле менеджера. В этот механизм лучше и встаиваться — это как с программным изменением форм: сначала сложно, потом станет понятно.
Про префиксы. В именах — на ваше усмотрение, конечно. Мне лично они вообще не нравятся. Типовой это объект или новый видно сразу по пометке справа. В синонимах префиксы — вообще зло. Какая разница пользователям какой разработчик в рамках какого проекта это добавил/изменил? На целостность интерфейса пользователя это не должно влиять. А чтобы найти добавленные/изменённые объекты я добавляю их для себя в соответствующие подсистемы: Доработки/Измененные, Доработки/Новые. К тому же, если вы добавили новый объект/реквизит, а затем в обновлении поставщик добавил такой же, то это тот случай, когда нужно проанализировать этот объект. Возможно, это и должен быть 1 реквизит, уже типовой. Если вы добавили рекв. Основание, затем поставщик добавил рекв. Основание. В результате вам не нужно 2 реквизита Мой_Основание и Основание. Вам нужен именно 1, с объединёнными типами.

Ну и, конечно, большинство изменения типовых объектов нужно добавлять в автотесты. Например, добавили/удалили типы в определяемом типе — добавили в проверку. При обновлении такие объекты можно смело обновлять, а после — прогнать тесты и они покажут всё, что нужно куда добавить/удалить.

После перехода на такие правила обновление сильно доработанной КА2 у меня вместо нескольких дней стало занимать полдня.

Спасибо вам! Крайне полезная статья! Но не очень понял момент, касающийся обновления конфигурации. Тут надо еще раз почитать и подумать.