Как лучше дорабатывать типовую конфигурацию: в расширении или основной конфигурации?
Для начала стоит вообще перечислить существующие подходы по доработке типовых конфигурций от 1С:
Метод №1: Доработка основной конфигурации
Метод, понятный любому программисту: предполагает полное или частичное снятие с поддержки основной конфигурации поставщика и внесение в него всех доработок.
Метод №2: Доработка в расширениях и дополнительных обработках
Тоже хорошо понятный метод, усиленно педалируемый в некоторых компаниях, причём безусловно. Часто указывают это требование в техническом задании, ничем не обосновывая. Предполагается, что исполнитель сумеет все требования из техзадания реализовать исключительно в расширениях конфигурации и местами в дополнительных обработках.
Метод №3: Гибридный подход
Метод предполагает, что поддержка основной конфигурации поставщика будет снята, но только для добавления новых объектов в основную конфигурацию. Чаще всего это новые реквизиты существующих объектов, новые регистры, т.е. носители хранимых в базе данных. Доработка логики ведется в расширениях и внешних обработках. Суть в том, что при удалении расширения данные в базе никак не пострадают, расширения можно легко динамически заменять и обновлять. Но такое разделение может быть и просто историческим: например, в далёком прошлом могли дорабатывать основную конфигурацию по методу №1, но потом всё новое начать разрабатывать в расширениях по методу №2.
Так какой же метод всё таки выбрать?
Однозначный и единственно верный ответ можно дать только в следующих исключительных случаях:
| Ключевой фактор | Метод | Комментарий | ||
|---|---|---|---|---|
| №1 (осн.конф.) | №2 (расш.) | №3 (гибрид) | ||
| Типовая конфигурация не поддерживает расширения | Да | Нет | Нет | УПП |
| Типовую конфигурацию обновлять не планируется | Да | Нет | Нет | Нет смысла усложнять себе работу |
| Пользователь планирует обновлять типовую конфигурацию автоматически, без привлечения квалифицированного специалиста | Нет | Да | Нет | Обновление без открытия конфигуратора и окна «Сравнения и объединения» конфигурации» возможно только с сохранением поддержки основной конфигурации. |
| Планируется размещение базы в 1С:Фреш | Нет | Да | Нет | В сервисе 1С:Фреш пользовательские доработки вносятся только в виде расширений |
| Планируется создание тиражируемого коробочного продукта | Нет | Да | Нет | Вы не можете продавать модифицированный БП, ERP или ЗУП, так как 1С это вам не GNU |
Если таких исключительных условий нет, то вам потребуется взвесить все "за" и "против". Для облегчения выбора можно воспользоваться нижеприведённой таблицей. Если какой-либо перечисленный фактор из таблицы имеет для вас значение - добавляйте числовое значение в общую сумму по столбцам. Строки не имеющие важного значения игнорируйте.
| Оценочный фактор | Метод | Комментарий | ||
|---|---|---|---|---|
| №1 (осн.конф.) | №2 (расш.) | №3 (гибрид) | ||
| Планируется периодически обновлять типовую конфигурацию, типовая конфигурация по важности и критичности стоит выше доработок. | 0 | 1 | 1 | Критически важный типовой функционал будет работать даже со сломанными и заблокированными после обновлениями расширениями. |
| Планируется периодически обновлять типовую конфигурацию, но важность и критичность доработок стоят выше типового функционала | 1 | 0 | 0 | Критически важные доработки и хранимые данные, находящиеся в основной конфигурации, гораздо труднее случайно удалить по ошибке. Отмечались случаи, когда неквалифицированный администратор по ошибке удалял расширения (вместе с хранимыми данными) |
| Планируется переход типовой конфигурации на новый крупный релиз | 1 | 0 | 1 | При смене релиза типовой конфигурации могут возникнуть непреодолимые ошибки на уровне СУБД, требующие полного удаления расширений. Соответственно потребуется сохранять данные расширений в выгрузку и загрузку их обратно после перехода. По срокам и объёмам данных это может стать неприемлемым. |
| Критическое значение имеет скорость накатывания типовых обновлений | 0 | 1 | 1 | Доработки кода в расширениях в большинстве случаев не потребуют время на тотальный анализ кода модулей. В любом случае можно быстро обновиться без затрат на анализ и сразу запустить в работу, исправляя выявленные ошибки расширений в ходе эксплуатации. |
| Качество конфигурации в целом после обновления имеет наивысший приоритет | 1 | 0 | 0 | Только путём сравнения-объединения конфигурации можно увидеть и проанализировать полностью все внесённые изменения, правильно оценить трудоёмкость обновления и исключить неожиданности. |
| Большинство планируемых доработок — это новый функционал в добавленных объектах. | 1 | 1 | 1 | С точки зрения сложности и качества обновления разницы нет |
| Большинство планируемых доработок — это изменение существующих типовых объектов. | 0 | 1 | 1 | Исправление типовых объектов в основной конфигурации постепенно приведёт к росту трудоёмкости обновления типовой конфигурации. |
| Большинство планируемых доработок в модулях возможно разместить в функциях и процедурах &Перед или &После | 0 | 1 | 1 | При обновлении типовой конфигурации не потребуется анализ сравнения и объединения кода (но изменение функциональности аргументов и результатов потребует анализа при любом варианте) |
| Большинство планируемых доработок в модулях потребует замену содержания с помощью &Вместо или &ИзменениеИКонтроль | 1 | 0 | 0 | При обновлении типового кода потребуется обязательный анализ сравнения и объединения кода. Механизм расширений не имеет такого функционала - придётся сравнивать тексты модулей вручную глазами в 2 окнах или с помощью отдельного инструмента. |
| Предполагается доработка объектов, которые невозможно доработать в расширении на текущей версии платформы | 1 | 0 | 1 | Например, в версии платформы 8.3.22 невозможно в расширении доработать объекты XDTO, а следовательно и форматы универсального обмена. |
| Доработки включают в себя web и http сервисы, обеспечивающие доступ к конфиденциальным данным, которыми требуется точечно управлять | 1 | 0 | 0 | При публикации на веб-сервере сервисы расширений можно опубликовать либо все сразу, либо ни один. Управление отдельными публикациями сервисов расширений не предусмотрено. |
| Это HiLoad | 1 | 0 | 0 | На высоконагруженных системах может потребоваться массовая доработка почти всех объектов. На HiLoad обычно типовая конфа снимается с поддержки. Пример: тотальное удаление из всех форм поля поиска. |
| Планируется дорабатывать функционал существующего расширения | 1 | 1 | 0 | Основная конфигурация в момент разработки не видит объекты расширений, одно расширение не видит объекты другого расширения: здесь либо дорабатывать само расширение, либо переносить всю разработку целиком в основную конфигурацию. |
Метод, набравший наибольшее количество баллов и можно выбрать как отправную точку. Я намеренно привёл здесь упрощенную таблицу, потому что в реальности цифры могут иметь и другие значения, а не только 0 и 1. Важность каждого фактора определяет сам клиент и у каждого свои предпочтения. Некоторые факторы могут быть более весомыми, чем другие, поэтому цифры в таблице можно и нужно уточнять в каждом конкретном случае.