Обновление современных конфигураций 1С перестро перестало быть линейным процессом сравнения двух cf-файлов. С появлением и активным внедрением механизма расширений сложность оценки возрастает в геометрической прогрессии. Если раньше мы анализировали только изменения в основной конфигурации, то теперь наличие множества расширений (иногда их число достигает десяти и более) заставляет нас пересматривать подходы к предварительному анализу. Рассмотрим подробно, как выстроить методику оценки, чтобы не ошибиться в сроках и учесть все скрытые риски.
Первое, с чем мы сталкиваемся — это необходимость выделения времени на саму процедуру анализа. Проанализируем ситуацию: когда конфигурация сильно доработана и содержит множество расширений, качественная оценка может занять от 5 до 10 часов и более. Попытка назвать цифру «на глаз» часто приводит к тому, что программист работает в убыток, либо клиент получает некачественный результат.
Рекомендуется использовать следующие организационные приемы:
Прежде чем приступать к ручному чтению кода, воспользуемся инструментами, которые предоставляет платформа 1С (начиная с версии 8.3.15). Это позволит автоматизировать рутину и сразу выявить «узкие места».
Разберем последовательность действий:
Этот инструмент за считанные минуты сформирует список критических проблем:
На основе полученного отчета мы можем сразу оценить объем технической правки расширений, не углубляясь в логику кода.
Трудоемкость обновления расширения напрямую зависит от того, как именно реализованы доработки. Проанализируем используемые аннотации в модулях расширений, так как каждая из них имеет свою «стоимость» адаптации.
Рассмотрим категории сложности:
&Перед и &После: Считаются наиболее безопасными. Они редко требуют вмешательства, так как не замещают основной код. При оценке на такие методы можно закладывать минимальное время (5-10 минут на проверку контекста).&Вместо: Самый трудозатратный и рискованный вариант. Если в новом релизе типовой код внутри замещаемого метода изменился, нам придется заново переносить эти изменения в расширение. Процесс требует построчного сравнения старого типового алгоритма и нового. На каждый такой метод при оценке стоит закладывать от 30 минут до 1 часа.Посмотрим на пример кода, требующего внимания:
&Вместо("РассчитатьСуммуДокумента")
Процедура Расш1_РассчитатьСуммуДокумента(Параметры)
// Если в типовой конфигурации добавился новый параметр
// или изменилась логика округления, этот код может
// стать причиной ошибок в учете.
ПродолжитьВызов(Параметры);
КонецПроцедуры
Выясним причину возможных конфликтов, когда расширений много. Часто одно расширение может зависеть от данных или логики другого. При оценке необходимо учитывать порядок применения расширений. Если обновление типовой меняет «фундамент» (например, базовый справочник), это может вызвать цепочку ошибок во всех семи расширениях одновременно.
Также проверим наличие собственных объектов в расширениях. Если расширение добавляет документы или справочники, которые ссылаются на типовые объекты, при удалении последних в новом релизе, связи в базе данных могут «побиться». Оценка таких участков должна включать проверку уникальных индексов и ссылочной целостности.
Если штатных средств конфигуратора недостаточно для понимания масштаба бедствия, воспользуемся продвинутыми инструментами. Рассмотрим вариант выгрузки конфигурации и расширений в файлы для внешнего сравнения.
Использование kdiff3 или WinMerge позволяет увидеть общую картину изменений в текстовом виде, что гораздо быстрее, чем открывать каждую форму или модуль вручную. Еще более профессиональный подход — использование 1C:EDT (Enterprise Development Tools). EDT на лету отслеживает зависимости и показывает, какие части расширения «сломались» после изменения основной конфигурации, что делает оценку максимально точной.
Для того чтобы ваша оценка была обоснованной, рекомендуем использовать следующую структуру расчета времени:
&Вместо: Количество замещающих методов × 0.7 часа.Использование такой детализации не только поможет вам точнее определить срок, но и станет весомым аргументом в переговорах с заказчиком, объясняя, почему обновление «типовой» конфигурации внезапно требует 40-50 часов работы программиста.