1. Корректно оформлять доработки комментариями и префиксами
Почему это важно?
При обновлении конфигурации требуется понимать, что различия между типовой и доработанной конфигурацией — это реальные доработки, а не какие-то ненужные изменения, внесенные неизвестно кем, неизвестно когда, с непонятной целью. Поэтому доработки нужно отделять от типового функционала визуально, чтобы они легко читались и не возникало путаницы.
Доработки в коде необходимо оформлять комментариями. В комментариях обычно указывается название компании, которая выполняет доработку, имя специалиста и дата внесения доработки.
Иногда также вписывается краткая информация о доработке либо код задачи во внутренней системе учета. Если код добавляется, то он оформляется с двух сторон — начальным и конечным комментариями. Если код модифицируется или удаляется, то исходный типовой код должен быть сохранен в виде комментария, а не просто удален или изменен.
Добавленные объекты метаданных — справочники, документы, регистры, а также реквизиты, формы и так далее — должны иметь узнаваемый префикс перед названием. После префикса желательно разместить знак подчеркивания «_».
Почему этого не делают?
Отсутствие правильного оформления доработок обычно означает недостаток культуры написания кода в компании-разработчике, отсутствие или несоблюдение установленных стандартов разработки.
2. Не делать частичное обновление конфигурации 1С
Что это значит?
Частичное обновление — это ситуация, когда в конфигурацию вносятся изменения, взятые напрямую из новой либо, в редких случаях, старой версии типовой конфигурации.
Зачем это делают?
Обычно к частичному обновлению 1С прибегают, когда необходимо как можно быстрее адаптировать конфигурацию к изменению законодательства (новой отчетности, новой редакции печатной формы и т. п.), но полноценное обновление было бы слишком сложным и дорогим, чтобы уложиться в сроки. Впрочем, иногда это делают из-за лени и нежелания обновлять конфигурацию полноценно.
Частичное обновление кажется отличным решением на короткой дистанции, так как позволяет получить новый функционал без значительных затрат. Однако в долгосрочной перспективе это очень плохое решение.
Почему так делать не стоит?
Чем больше внедряется частичного обновления, тем сложнее будет следующее полноценное обновление. Со временем это накапливается как снежный ком. При обновлении будет тяжело разбираться в огромном количестве изменений и вычленять из них реальные доработки. Иногда стоимость последующего полноценного обновления может увеличиться на порядок, а в отдельных случаях может и вовсе потребоваться перевнедрение.
Если все-таки делать, то как?
В некоторых ситуациях частичное обновление — это необходимое зло и отказаться от него не получится. Но можно минимизировать последствия для будущих обновлений:
- Не накапливать частичное обновление, сразу проводить полноценное обновление, как только появится такая возможность.
- В отличие от реальных доработок, при частичном обновлении лучше не оформлять код комментариями — это может смутить специалиста, ему придется сначала разбираться, является ли доработка реальной. Отсутствие комментариев будет контрастировать с реальными доработками (см. предыдущий пункт) и станет сигналом, что данные изменения можно затирать.
- По возможности брать объекты (модули, отчеты) из других версий целиком, а не копировать отдельные процедуры и функции.
- Составить и сохранить точный список объектов, в которых есть частичное обновление. Эта информация пригодится в последующем полноценном обновлении.
3. Не менять запросы с использованием конструктора запросов
Зачем это делают?
Разработчики, незнакомые со стандартами разработки 1С, могут посчитать, что конструктор запросов — это удобный способ внесения доработок в запрос.
Почему так делать не стоит?
В идеальном мире конструктор запросов действительно должен быть подобным удобным инструментом.
В реальности, к сожалению, существует большая разница между стилем оформления текста запросов, созданных конструктором, и запросов в типовых конфигурациях.
Если модифицировать типовой запрос конструктором запросов, то в лучшем случае испортится его форматирование, в худшем — пропадет часть функционала, которая в исходном запросе могла быть реализована в виде комментариев, поскольку конструктор запросов удаляет все комментарии. Даже если пострадает только оформление, это может добавить проблем при последующих обновлениях. Например, добавляя одно поле в большом запросе на 1000 строк, при использовании конструктора поменяются сотни строк, а при правильном внесении доработки будет добавлена лишь одна строка модификации плюс две строки комментариев.
Впрочем, все вышеописанное не означает, что конструктор запросов использовать нельзя. Он подходит для контроля корректности запроса и отсутствия в нем синтаксических ошибок. Главное — закрывать конструктор, не сохраняя запрос, а доработки вносить напрямую в код.
4. Избегать копирования типовых объектов и кода
Что это значит?
Частой практикой ведения доработок является принцип «если нужно что-то изменить, то скопируем типовой объект, внесем изменения туда и будем использовать его вместо оригинала». Например, когда надо доработать форму, копируют типовую, вносят доработки и устанавливают ее основной. Или, когда надо доработать типовой модуль, копируют его и вносят изменения, а также меняют места вызовов.
Подобный стиль — плохая идея, теряется связь между доработанным объектом и оригиналом, доработанный объект при обновлениях перестает получать типовые изменения и начинает устаревать.
Если типовой объект в новых версиях сильно меняется, то это может вызвать серьезные проблемы. Например, большое количество вызовов удалившихся типовых процедур и функций, обращения к изменившимся или удаленным типовым реквизитам, конфликт с типовыми процедурами и функциями из других модулей, вызываемыми в данном объекте.
Адаптация такого объекта под новую версию может стать очень трудной задачей. Даже если попытаться обновить его на основе типового объекта, сопоставив вручную, то предшествующее устаревание вызовет множество ложных изменений, которые выглядят как частичное обновление в обратную сторону. Искать реальные доработки будет очень тяжело.
Описанное справедливо и на меньших масштабах: для скопированных типовых процедур, функций или даже отдельных кусков кода. Нередко можно встретить случаи, когда для доработки текста запроса он полностью копируется и затем переприсваивается.
Зачем это делают?
Подобное ведение доработок, как и в случае с частичным обновлением, может показаться очень удобным на ближней дистанции, потому что добавленный объект не потребует обновления. Но в долгосрочной перспективе с ним будет огромное количество проблем из-за устаревания.
5. Не использовать расширения для доработки типовых объектов
Что это значит?
Расширения позиционируются как удобный способ внесения изменений без модификации конфигурации. Однако наш опыт говорит об обратном — расширения сильно усложняют обновление конфигурации. Основная причина, как в предыдущем пункте с копированием объектов — нарушение связи между оригиналом и доработкой.
Расширения, особенно если их много, приводят к серьезной фрагментации кода. В случае использования директивы &Вместо получается еще и излишнее копирование типового кода. Отсюда те же проблемы, описанные в предыдущем пункте. При обновлении сильно повышается вероятность ошибок, так как при работе с расширениями очень сложно уследить за всеми типовыми изменениями в заимствованных объектах и коде.
Отдельным пунктом можно выделить особо сомнительный случай, когда в основной конфигурации есть обращения к расширениям. Это еще более странный способ ведения доработок. При нем конфигурация теряет независимость от расширений и без них становится неработоспособной, что противоречит самому принципу расширений «расширять конфигурацию, сохраняя её самостоятельность».
Зачем это делают?
Существует мнение, что расширения упрощают доработку конфигурации. Если «в моменте» это так, дальнейшие обновления они, наоборот, сильно усложняют. Но во время принятия решения о создании расширений об этом не задумываются.
Если все-таки делать, то как?
Расширения не рекомендуется использовать для модификации типовых объектов. Однако они могут оказаться довольно удобными для добавления новых объектов в конфигурацию. Желательно, чтобы новые объекты были обособленными и не зависели от функционала конфигурации. В этом случае вероятность проблем при обновлении близка к нулю.
