Когда вы заказываете доработку BAS, исполнитель редко спрашивает, как именно ее реализовать. А зря: от этого выбора зависит не столько цена самой доработки, сколько стоимость всех последующих обновлений. Разница может составлять часы каждый месяц на протяжении всей жизни системы.
Разберем оба пути так, чтобы вы могли задать правильные вопросы до начала работ.
Две дороги для одной задачи
Представим обычную задачу: нужна печатная форма, которой нет в типовой конфигурации. Реализовать ее можно двумя способами.
Способ первый — расширение. Программист создает отдельный файл-расширение (.cfe), в котором описывает только новую форму. Типовая конфигурация остается нетронутой, словно к ней никто не подходил.
Способ второй — изменение конфигурации. Программист открывает типовую конфигурацию в конфигураторе, снимает нужный объект с замка́ поддержки и дописывает код прямо в тело программы.
Результат для пользователя одинаковый: кнопка печати появилась, форма работает. Разница в том, что произошло с самой программой.
Что такое «поддержка поставщика»
Типовая конфигурация BAS поставляется на поддержке разработчика. Это означает, что программа знает: этот объект — типовой, его автор — поставщик, и при выходе нового релиза он обновится автоматически.
Когда вы изменяете объект в теле конфигурации, вы фактически заявляете: «теперь за этот кусок отвечаю я». Объект частично или полностью снимается с поддержки. Программа больше не может обновить его самостоятельно, потому что не знает, какие из ваших изменений нужно сохранить, а какие можно перезаписать.
Ключевая теза: снятие с поддержки — это не поломка и не ошибка. Это передача ответственности за часть кода от разработчика к вам.
Как это ощущается при обновлении
Вот где выбор превращается в деньги.
Обновление типовой конфигурации. Стандартная процедура. Сравнение, применение, проверка. Предсказуемая по времени и почти без рисков.
Обновление конфигурации с изменениями. Процедура превращается в отдельную работу:
- сравнить изменения нового релиза с вашими доработками;
- выяснить, затронул ли релиз те же объекты, которые вы изменили;
- перенести и адаптировать код там, где возник конфликт;
- протестировать доработанный функционал;
- проверить связанные документы и отчеты;
- перенести изменения в рабочую базу.
Главная проблема здесь не в объеме, а в непредсказуемости. Если релиз затронул те же механизмы, что и ваша доработка, работа может занять в разы больше времени, чем планировалось. А регламентированную отчетность обновлять нужно вовремя, независимо от того, удобный это момент или нет.
Обновление базы с расширением. Проходит по стандартной процедуре. Расширение нужно проверить после обновления, но оно живет отдельно, и в большинстве случаев работает дальше без правок.
Почему расширение дешевле в обслуживании
| Расширение | Изменение конфигурации | |
|---|---|---|
| Конфигурация на поддержке | Да | Частично или полностью нет |
| Процедура обновления | Стандартная | Отдельная работа каждый раз |
| Предсказуемость стоимости обновлений | Высокая | Низька |
| Ризик конфлікту з новим релізом | Низький | Зростає з кожною доробкою |
| Відокремлення вашого коду від типового | Повне | Немає |
| Можливість швидко вимкнути доробку | Так, одним перемикачем | Ні, потрібна робота в конфігураторі |
| Передача системи іншому підряднику | Просто | Складно |
Останній рядок варто прочитати уважно. Розширення — це фактично документація ваших змін: видно, що саме і де змінено. У конфігурації зі змінами новому підряднику доведеться спершу порівнювати вашу базу з типовою, щоб зрозуміти, з чим він має справу. Це час, який ви оплатите.
Коли розширення не підходить
Було б нечесно стверджувати, що розширення вирішує все. Є задачі, де без зміни конфігурації обійтися складно або невиправдано дорого:
- глибока переробка типових механізмів — наприклад, зміна логіки проведення документа на рівні, де розширення довелося б перевизначити половину модуля;
- старі конфігурації, у яких механізм розширень реалізовано обмежено;
- масштабна галузева доробка, коли змінюється сама модель обліку, а не окремі ділянки;
- бази, які вже давно знято з підтримки — тут дискусія часто безпредметна, конфігурація вже змінена попередніми підрядниками.
В последнем случае есть отдельное решение: вернуть базу на поддержку. Это самостоятельный проект — перенести имеющиеся доработки в расширение, обновиться до актуального релиза и далее обслуживать систему по стандартной процедуре. Работа разовая, но она окупается на обновлениях, особенно если базу планируют использовать годами.
Вопросы, которые стоит задать исполнителю
Перед тем как согласовать доработку, спросите:
- Как именно будет реализована доработка — расширением или изменением конфигурации? Ответ «как получится» означает, что об этом не думали.
- Если меняем конфигурацию — какие именно объекты снимаются с поддержки? Список должен быть конкретным.
- Как это повлияет на стоимость следующих обновлений? Оценка может быть приблизительной, но она должна прозвучать.
- Можно ли решить задачу расширением, пусть и немного дороже сейчас? Иногда разница в два часа на старте экономит десятки часов за год.
- В каком виде я получу доработку? Файл .cfe или файл сравнения конфигураций — это ваш актив, который вы сможете передать другому исполнителю.
Наша позиция
Если задача технически решается расширением, мы выбираем расширение. Даже когда это немного дольше на этапе разработки.
Причина проста: мы видим систему не в момент сдачи доработки, а на протяжении лет обслуживания. База, которую меняли в конфигураторе каждые несколько месяцев на протяжении пяти лет, превращается в систему, где каждое обновление регламентированной отчетности становится мини-проектом с непредсказуемыми сроками. Причем больше всего это бьет по клиенту именно тогда, когда времени нет — в отчетный период.
Поэтому в наших тарифах для конфигураций, снятых с поддержки, действует надбавка к абонентской плате, а адаптация кода при обновлении оценивается отдельно. Это не штраф, а отражение реального объема работ: такая база действительно требует больше внимания.
Кратко
- Расширение оставляет конфигурацию на поддержке, обновления проходят стандартно, ваш код отделен и документирован.
- Изменение конфигурации снимает ее с поддержки, и каждое следующее обновление становится отдельной работой с непредсказуемой стоимостью.
- Каждая доработка в теле конфигурации удорожает все последующие обновления — эффект накопительный.
- Бывают задачи, где без изменения конфигурации не обойтись, но это должно быть осознанным выбором, а не следствием того, что так было быстрее программисту.
- Базу, снятую с поддержки, можно вернуть на поддержку. Это отдельный проект, который окупается на обновлениях.
Если не знаете, в каком состоянии ваша конфигурация, начните с аудита: мы посмотрим, какие объекты сняты с поддержки, сколько в базе доработок и в каком виде они реализованы, и скажем, имеет ли смысл возвращать систему на поддержку.