Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают... А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Кейс 3. Доработка типовой конфигурации.
Большинство разработчиков и руководителей проектов считают, что дорабатывать типовую конфигурацию нужно только в крайних случаях. Все стремятся решить задачу либо внешней обработкой/отчетом, подпиской на событие, либо регламентным заданием. Сейчас к этому списку вредоносных решений добавились расширения. В своей практике крайне редко пользуюсь подобными приёмами программирования, т.к. хорошо владею инструментами обновления конфигураций. Не испытываю сильных трудностей при пропуске большого числа релизов и сильно переработанном коде. Надеюсь, благодаря статье и у Вас появится больше инструментов для работы.
Итак, как мы выяснили, главное, что нужно сделать, - разобраться со сценариями работы типовой конфигурации. Т.к. конфигурация типовая, мы всегда можем найти огромное количество инструкций, описаний, статей, книг и т.д. Вот в какой последовательности стараюсь изучать типовое решение, точнее каждый блок в типовом решении:
1. Предметная область. Все типовые конфигурации довольно сильно привязаны к предметной области. Отсутствие знаний по предметной области не позволит Вам полноценно разобраться в происходящих бизнес-процессах. Как следствие, выявить все сценарии работы пользователей, подлежащие автоматизации - затруднительно. Настоятельно рекомендую начинать именно с этого. В моей сфере (ЗУП), предметной областью является законодательство (ТК РФ, НК РФ), правила заполнения отчетности, локальные нормативные документы общества (положение об оплате труда, положение о ведении кадрового учета, положение о премировании).
2. Архитектура решения. На этом этапе необходимо разобраться, в нужной Вам подсистеме. Вот что следует изучить:
а. Какие операции выполняются в рамках подсистемы.
б. Какая справочная информация используется. Какие особенности заполнения справочной информации.
в. Какие регистры, и как используются для обеспечения работоспособности подсистемы.
г. Какая отчетность на основании каких данных формируется.
Конечно, не для каждой задачи требуется столь глубокий анализ. Но при решении сложных задач, требующих больших доработок это необходимо.
3. Назначение объектов метаданных. Для более мелких задач можно начать с разбора конкретного документа/справочника/отчета и т.д. Для некоторых задач не имеет никакого значения, в какой подсистеме этот объект метаданных, и как подсистема функционирует. На данном этапе необходимо выяснить, на основании каких данных объект заполняется, и какие данные объект меняет.
4. Сценарии работы. Сценарии работы - основа любой разработки! Этот пункт является основным, и пропускать его ни в коем случае нельзя! Сценарии работы следует изучить не только в месте доработки, но и в связанных объектах метаданных. Если поменять движения документа, и не разобраться, как формируются отчеты на основе измененных движений - сломаем отчет. Если по регистру заполняет другой документ - сломаем авто заполнение другого документа. Если изменения вносятся в интерфейс или печать - необходимо изучить эти механизмы до выполнения доработок.
5. Работа интерфейса. Данный пункт является продолжением изучения сценариев работы. Выделил его в отдельный пункт, т.к. часто сталкиваюсь либо со сломанным интерфейсом, т.е. в неучтённых ситуациях появляются ошибки, либо неверно отображается форма. Либо пишут новые кнопки, которые на самом деле уже есть! В типовых конфигурациях следует учитывать наличие динамически создаваемых реквизитов, т.е. их нет на форме, они создаются программным путём. На наличие таких элементов указывает наличие пустых групп в дереве реквизитов управляемой формы (слева вверху). Например, в типовых документах встречаются пустые группы "ПодписиГруппа" для указания подписантов, или "ГруппаИсправление" для отображения универсальных команд механизма исправления, или "ГруппаДополнительныеРеквизиты" для отображения дополнительных реквизитов, указанных для конкретного документа. Аналогичные группы есть и в шапке документов. Всё это необходимо учитывать при изменении интерфейса.
6. Программный код. Изучение программного кода позволяет лучше понять каждый в отдельности сценарий работы. При прохождении отладчиком сценария можно увидеть, как именно срабатывает код, какие данные возвращают запросы, какие движения пишутся в регистры, откуда получаются данные, как работает печать и почему именно так и т.д.
Код типовой конфигурации часто усложнён универсальными процедурами или целыми модулями. Они сложны для понимания, но зачастую программный интерфейс конфигурации следует воспринимать как ещё одну процедуру или функцию встроенного языка. Никто же из Вас не пытается вникнуть, как срабатывают функции встроенного языка. Мы просто изучаем, что у них на входе и что на выходе. Также и здесь, подробнее ниже.
Программный код типовых решений содержит сценарии для всей страны... Поэтому на данном этапе требуется локализовать место, которое Вы планируете доработать. И уже изучать более мелкий участок кода.
Разобрав все указанные аспекты типовой конфигурации, скорей всего, у Вас получится выполнить доработку аккуратно, не сломав сценарии типовых объектов метаданных.
Также Ваша доработка должна быть выполнена в общей стилистике дорабатываемой конфигурации. Необходимо соблюдать стандарты разработки, делать так, чтоб решение легко обновлялось. Детали обновления описаны ниже.
Кейс 4. Обновление доработанной типовой конфигурации.
Прежде, чем описывать сам кейс, хочу развенчать некоторые мифы и дать некоторые подсказки к обновлению:
Миф №1. Не нужно дорабатывать типовую конфигурацию, иначе не сможем её потом обновлять. Главное - дорабатывать грамотно, соблюдать стандарты разработки, не создавать дубли типовых объектов метаданных для изменения и т.д. Если не делать глупостей в процессе разработки - обновление довольно несложный процесс.
Миф №2. Нельзя дорабатывать формы типовых объектов, будет сложно их обновить. Сильно ли Вы удивитесь, если узнаете, что перенести свои новые реквизиты на обновленную форму можно через простое действие Скопировать + Вставить. Не нужно каждый новый реквизит создавать заново! Не обязательно новые элементы на форму добавлять программно! Так Вы ещё один или несколько модулей сделаете нетиповыми.
Миф №3. Обновить конфигурацию может только самый опытный сотрудник. Ничего подобного! Мне 15 лет назад дали в хлам переписанную Бухгалтерию 7.7 и за месяц я её обновил! На тот момент мой опыт составлял 3,5 года. Учитывая то, что начинал я в регионе, опыт был так себе! Главное не бояться и придумать какую-то систему для переноса доработок в новый релиз.
Теперь подсказки:
Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний! Часто слышу от коллег, что при пропуске 5-10 релизов, они последовательно выполняют обновление своей конфигурации на каждый из пропущенных релизов. Ничего хуже и придумать невозможно, как выполнить одну и ту же работу 5-10 раз! Почему так делают:
-- Обработчики обновления могут неверно сработать, если запустить их сразу на все релизы... Это впору записать в очередной миф. Обработчики обновления так написаны, что выполняются последовательно, вне зависимости от количества пропущенных релизов. Сам выполнял обновление, когда не релиз поменялся, а редакция!
-- Не получится сохранить СФ из-за большого количества изменений... Ни разу с таким не сталкивался... Имеется ввиду, что при сохранении возникнут какие-то конфликты в данных. Например, если в регистре есть записи, то могут быть проблемы с сохранением такой конфигурации. Об этом можно подумать заранее, и найти решение.
Подсказка №2. Выполнять обновление необходимо в режиме "Показать дважды измененные объекты". Можете почитать что это за режим в деталях. Главный его плюс - экономия времени! Ведь обновить требуется только те объекты метаданных, которые и Вами были доработаны и фирма 1С изменила объект в одном из пропущенных релизов. Остальные объекты Вы можете считать уже обновлёнными!
Подсказка №3. Для обновления на новый релиз Вам необходимо создать несколько баз. Перечислю их и опишу зачем каждая:
База 1. Копия до обновления. Здесь мы можем смотреть код и состояние форм, которые были до перехода на новый релиз. Часто неудобно оценивать правильность кода через сравнение объединение объектов.
База 2. Типовая конфигурация старый релиз. Здесь можно проверить как было в типовом релизе до доработок. Это требуется, т.к. не все разработчики понятным образом отмечают границы своих доработок.
База 3. Типовая конфигурация новый релиз. Аналогично база нужна, чтоб посмотреть как сделано в новом релизе. Рекомендуется здесь иметь демо-базу, чтоб иметь возможность тестировать новые механизмы.
База 4. Обновляемая база. Здесь всё просто - после завершения работ именно в этой базе будет новая конфигурация с выполненными ранее доработками.
База 5. Типовая конфигурация старый релиз для сравнения. В этой базе мы запускаем сравнение/объединение с конфигурацией нового релиза. Это требуется, чтоб понять объём доработок в отдельных объектах метаданных. Иногда нужно сделать выбор, что переносить: свои доработки или доработки типового релиза. Бывает какие-то процедуры мы сильно переписали, а в типовой конфигурации всего пару строк поменяли. Соответственно проще в эту процедуру внести изменения типового релиза. Это сильно экономит время!
Пора описать подробности кейса:
Надо понимать, что здесь будет не инструкция "Как обновить нетиповую конфигурацию". Кейс с разбором запросов осознанно написан позднее, т.к. для обновления эти знания не нужны. Вопросы обновления форм здесь также не затрагиваются. Рассказ ведется как ответ на вопрос: "Как найти место, куда вставить дописанный код?"
Итак будет 3 ситуации:
1. Изменения внесли в запрос.
2. Изменения внесли в обычный код.
3. Изменен запрос схемы компоновки данных.
1. Перенос изменений в запросах:
а. Первым делом нужно проверить, изменился ли структурно запрос, в котором была доработка? Т.е. в типовой конфигурации могли всего лишь добавить поля новые в запрос, переместить временную таблицу в другую часть запроса, часть запроса убрать в другую процедуру в результате рефакторинга кода. Это всё не страшно, Вы просто ищете по наименованию временной таблицы (в которую поместили), либо по названию таблицы источника запроса. Вставляете свои доработки в найденное место и радуетесь, что не надо писать заново.
б. Если в текущей процедуре/функции не обнаружен кусок запроса, не стоит впадать в панику. Нужно сделать следующий шаг: посмотреть, после какого кода был Ваш кусок кода? Что сейчас на этом месте? Очень часто Вы обнаружите переход в функцию общего модуля. Зайдя в неё можно легко обнаружить нужный запрос и внести в него изменения.
в. Если всё таки запрос был структурно изменен... Сначала, что значит структурно изменен?
-- Изменилась таблица, из которой данные получались. Иногда в типовой конфигурации меняют состав регистров, состав измерений регистра. Т.е. старый помечают как Удалить... А новый создаётся с другим составом измерений.
-- Запрос начал делаться в 2 этапа. Такие события происходят для оптимизации работы с использованием индексов.
В такой ситуации Вам нужно понять, что было изменено в запросе в версии до обновления:
-- Добавились условия
-- Добавились поля
-- Добавилась связь между таблицами
-- Добавилась собственно новая таблица и всё вышеперечисленное.
Очень полезно в сложных случаях через отладчик смотреть, как выглядит таблица после доработки. Вы тогда можете сравнить её с таблицей "до" и станет понятно, какие изменения внесены в запрос.
Далее начинаете к новой архитектуре по частям применять внесённые ранее изменения. Ситуаций, когда вот совсем некуда вставить свой код, не так уж много! Если разбить код на маленькие кусочки, то каждый маленький кусочек становится вполне понятным, даже если неизвестна ни постановка, ни сценарий работы! Как видно из описания, знать это необязательно!
2. Перенос изменений в коде.
На самом деле. алгоритм вставки кусков обычного кода (не запросов) точно такой же!
а. Ищем исходное место кода, определяем - есть куда вставить или нет? Возможно, часть кода вынесли в отдельную процедуру/функцию. Здесь искать надо прямо целую строку, которая предшествует написанному Вами коду. Если её нашли и далее код похож на то место, в которое Вы его вставили - радуемся результату.
б. Возможно написали в другом месте. Часто процедуры целиком переносят в другие общие модули. В таком случае надо поискать по названию процедуры/функции по всем текстам. Этот совет также помогает, когда Вы использовали типовой программный интерфейс и в том виде, как написано, не срабатывает.
в. Если опять плохой вариант, то пробуем следующие действия:
-- Для начала необходимо определить, где старый код реализован по-новому. Код бесследно не стирают, его оптимизируют, проводят рефакторинг, делают более универсальным и т.д. Крайне редко в типовых конфигурациях удаляют реализацию каких-то сценариев. Обычно добавляют новые.
-- Для того, чтобы найти, необходимо ответить на вопрос: "Каким действием пользователя запускается код?". Иногда код может запускаться без пользователя через подписки на события и регламентные задания. Чтобы найти путь к новому коду, нужно посмотреть сначала тот же путь в старом решении. Здесь поможет установка точки останова в месте доработки и через стек вызовов (пункт меню в конфигураторе) можно найти путь к месту, из которого вызван нужный Вам код.
-- Когда определён путь в старой реализации, начинаем искать его в новой реализации. Для этого через стэк вызовов пошагово смотрим, на каком шаге изменилась реализация? Т.е. где-то код свернёт в другой модуль, в этом другом модуле процедура/функция будет иметь примерно такое же название, как и раньше.
-- Когда определили место новой реализации, пытаемся разобраться в старой реализации, что было добавлено? Как и с запросами, мы смотрим на добавленные условия, дополнительная обработка коллекций значений, какая-то дополнительная функция для обработки этой коллекции... Когда мы разложили весь код на простые составляющие, можно понять, что нужно написать в новой реализации, даже не зная сценария работы!
Конечно, может возникнуть ситуация, когда нужно вникать в новые сценарии и заново проводить доработку по какой-то задаче. Но ситуация эта не распространённая. В моей практике, описанные шаги помогают провести обновление.
ВАЖНО: Не нужно бояться ситуаций, когда требуется доработка с нуля. Об этом необходимо смело информировать руководителя проекта или архитектора. Наверняка эти люди попытаются ускорить обновление и найдут исполнителя на новую задачу. Если Вы тратите излишне много времени на решение нерешаемого - это негативно сказывается на сроках обновления и Вашей карме!
Остальные части доступны по ссылкам:
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Часть 3. Разбор и доработка запросов
Часть 4. Программный интерфейс. Исправление чужих доработок.
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
1. Кто такой архитектор. Редакция 2!
2. Пример работы с файлами odt в клиент-серверной модели работы
