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

Прежде всего, необходимо понимать, что доработку типовой конфигурации не стоит воспринимать как совместную работу с разработчиками, скорее как работу в другом слое от разработчиков типовой. Не смотря на то, что модифицируемая конфигурация находится на поддержке типовой, необходима возможность всегда видеть доработки. Это сильно поможет при поиске ошибок, выполнении code-review и при разрешении конфликтов обновления конфигурации. В примерах используется префикс МОД_, но можно выбрать любое другое сочетание символов. Некоторые используют сочетание строчных букв без символа (например мод), но такое выделение гораздо менее заментно.

Выделение изменений

Новые объекты метаданных

Префикс МОД_ с причиной изменнения в комментарии. У добавленной табличной части с префиксом МОД_ добавлять префикс МОД_ для реквизитов не нужно

Изменение типовых модулей

// +МОД

// старая версия кода

новая версия кода

// -МОД

Экспортные процедуры типовых модулей - префикс МОД_

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

Неизменяемые объекты

Форма- все изменения вносить кодом, либо использовать подсистему Модификация управляемых форм

Роль - добавить новую

Подсистемы - добавить подчиненную

Расширения конфигурации

Когда с выходом платформы 8.3 появился механизм разделения данных и первые конфигурации, которые поддерживают модель SaaS, стало очевидно, что нужна возможность для кастомизации отдельных областей данных. Это необходимость, и разработчики платформы реализовали это в версии 8.3.6. После этого кто-то решил, что стоит использовать данный механизм для доработки типовых конфигураций, а некоторые даже стали говорить, что другие способы внесения изменений непреемлемы.

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

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

Кроме этого можно столнуться с ошибками в самых неожиданных местах. Опять же нужно всегда помнить - расширение это необходимость для модели SaaS, для обычных проектов кроме неудобства и сложностей обновления вы ничего не получите.

О чем следует помнить при доработке типового решения

Разработчики не видят ваших изменений и будут развивать свое решение не оглядываясь на ваши доработки

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

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