бизнес-процессов предприятия): «Можно ли решить поставленную задачу штатными средствами прикладного решения, не внося изменений в конфигурацию? Можно ли для решения задачи использовать универсальные механизмы, встроенные в прикладное решение?»

И только если ответом будет «нет, нельзя», необходимо задать себе второй вопрос: «Каким образом модифицировать прикладное решение, чтобы не усложнить процесс дальнейшего сопровождения?»

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

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

1) Использовать механизм подсистем. Перед тем как приступить к внесению в конфигурацию изменений и доработок, необходимо создать корневую подсистему НовыеФункции и две подчиненные подсистемы МодифицированныеОбъекты и НовыеОбъекты (имена подсистем, разумеется, могут быть любыми). К первой из подчиненных подсистем следует отнести все объекты прикладного решения, которые в ходе работ подверглись модификации, ко второй – объекты, которые были добавлены в конфигурацию. Для чего это нужно? Это позволит в любой момент (в том числе и при сравнении и объединении с новой конфигурацией поставщика) быстро выделить из конфигурации все объекты, которые были изменены или добавлены.

2) Использовать префиксы в именах добавляемых объектов. Имя любого объекта, добавляемого в конфигурацию, должно начинаться с префикса (например, мы хотим добавить регистр сведений для хранения информации о прогнозе погоды, он должен получить имя вида преф_ПрогнозПогоды). Разумеется, в синонимах объектов никаких префиксов не требуется. Для чего это нужно? Мы получаем гарантию, что имена «наших» объектов и имена объектов, добавляемых в конфигурацию поставщиком, ни при каких обстоятельствах не совпадут. Это правило применяется абсолютно ко всем объектам, свойствам и реквизитам, в том числе и к подсистемам.

3) Не модифицировать экранные формы, созданные поставщиком. Если требуется внести изменения в экранную форму какого-либо объекта (например, элемента справочника), следует скопировать форму, созданную поставщиком, сделать необходимые доработки в скопированной форме и назначить ее основной формой объекта. Для чего это нужно? Во-первых, при установке обновлений поставщика не придется забивать себе голову настройкой режима объединения экранных форм. Во-вторых, в конфигурации всегда будет доступна «родная» форма поставщика, которую можно проанализировать на предмет внесенных поставщиком доработок и исправленных ошибок.

4) Не модифицировать роли (наборы прав доступа), созданные поставщиком. С ролями нужно поступать так же, как с экранными формами: либо вносить изменения только в скопированные объекты поставщика, либо создавать свои собственные. Изменить набор ролей, доступных конкретному пользователю информационной базы, намного проще, чем проверить и восстановить десяток опций доступа для нескольких сотен объектов конфигурации.

5) Не вносить никаких изменений в те обработчики объектов, к которым можно получить доступ через механизм подписки на события. Например, если требуется изменить логику формирования движений документа (скажем, добавить движения по вновь созданным регистрам накопления), не нужно модифицировать код модуля документа. Вместо этого необходимо создать новую подписку на событие, в качестве источника указать искомый документ и событие ОбработкаПроведения, а управляющий движениями документа код поместить в привязанный к подписке обработчик. Для чего это нужно? При установке обновлений поставщика не придется забивать себе голову настройкой режима объединения модулей объектов, а после обновления рыскать по обновленным модулям в поисках волшебного ключевого слова «//{{MRG[».

6) Использовать механизм хранилища конфигурации, даже если разработка ведется одним человеком и вносимые в конфигурацию изменения незначительны. Хранилище конфигурации – это не только инструмент групповой разработки. Это полная история сделанных изменений (а если разработчик не ленится писать комментарии, то и полное описание проделанной работы). Это возможность отменить любое неудачное действие и вернуться в состояние «за полчаса до того, как в мою голову пришла эта глупая идея». Наконец, хранилище позволяет установить обновление поставщика и выполнить все необходимые проверки в тестовой информационной базе, а затем обновить конфигурацию рабочей информационной базы буквально двумя кликами.

Этот перечень можно продолжать, но углубление в сугубо технологические вопросы больше соответствует формату методического пособия, чем формату статьи. В качестве заключения хотелось бы еще раз повторить основные принципы поддержки и доработки прикладных тиражных конфигураций «1С: Предприятие 8». Итак:

• если есть возможность вообще обойтись без внесения изменений в типовую конфигурацию, ее нужно использовать. «Изменения ради изменений» – верный путь к проблемам;

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

• и наконец, если без прямой модификации объектов типовой конфигурации нельзя обойтись, нужно, по крайней мере, производить модификацию с умом и тщательно документировать все вносимые изменения. В кризисных ситуациях (без которых не обходится ни одно внедрение) подобные документы спасли профессиональную репутацию не одному десятку специалистов.