Ревизия доработок при переезде на новую конфигурацию

               Меня зовут Елена Иваница, разработчик 1С в компании Programming Store.

Расскажу в статье о методике, выработанной при переезде с 1С:ДО 2.1 на 1С:ДО 3.0. Может также применяться при переходе с 1С:УПП на 1C:ERP, 1C:ERP на 1C:ERP УХ и т. п. Учтены все необходимые доработки при переезде на новую конфигурацию и предупреждены возможные ошибки. 

Содержание:

1. Применимость методики.

2. Описание методики

3. Пример: вычленения доработок по новому реквизиту

Применимость методики

Методика, описанная в статье, выработана при переезде с 1С:ДО 2.1 на 1С:ДО 3.0. Может также применяться при переходе с 1С:УПП на 1C:ERP, 1C:ERP на 1C:ERP УХ и т. п.

Может применяться:

1. если необходимо переехать с одной конфигурации на схожую с сохранением текущих доработок;

2. для ревизии текущих доработок: если нужно составить список всех существующих доработок или найти и вычистить устаревшие.

Методика подойдёт, если:

• аналитик и разработчик плохо или только частично знакомы с доработками;

• отсутствует документация;

• отсутствует или плохо описано ТЗ;

• на проекте часто меняются аналитики и/или разработчики.

Преимущества методики:

• каждая доработка переносится в отдельности и сразу же тестируется;

• количество ошибок после перехода сводится к минимуму;

• остается документация с описанием всех текущих доработок конфигурации;

• конфигурация очищается от легаси-кода.

Недостаток методики: подобный подход занимает очень много времени. Оно будет уходить на постоянный перезапуск сравнений/объединений и глобальных поисков. Словесное описание незнакомых доработок тоже может занять время, если не осталось ТЗ или документации с описанием доработки или людей, владеющих информацией, как правило, это аналитик и разработчик по задаче.

Описание методики

Как все найти и ничего не забыть? В первую очередь разработчику нужно выделить все источники, в которых могут находиться доработки:

• в конфигурации;

• в расширениях;

• в дополнительных отчетах и обработках;

• в полях (как правило, строка неограниченной длины), предназначенных для хранения текстов кода, выполняемых при помощи Выполнить или Вычислить;

• в отчетах, обработках, не подключенных как дополнительные, а открываемые при помощи Файл ? Открыть;

• в интегрируемых системах — файловые обмены, веб- и http-сервисы. Для ИС будут те же самые источники.

В дальнейшем поиск необходимо производить по всем этим источникам. Исключать источники из поиска не рекомендуется даже частично, даже если доработка изначально была сделана вами. Если вы владеете всей информацией обо всех доработках, то эта методика не нужна.

Затем нужно подготовить источники к будущим поискам:

• Создать базу с конфигурацией и без данных, из нее будут вычищаться уже описанные доработки.

• Создать или актуализировать копию рабочей базы, на которой можно будет проверить работу доработки до вычищения или пройтись отладкой, если из кода непонятна суть доработки.

• Выгрузить дополнительные отчеты и обработки.

• Туда же выгрузить внешние отчеты и обработки.

• Код, хранящийся в пользовательском режиме, также сохранить в текстовый файл, можно всё в один.

Необходимо настроить поиск по всем описанным выше источникам. Последовательность действий такая:

1. Делаем сравнение с конфигурацией поставщика.

2. Выбираем изменение, которое будем описывать, лучше начать с новых реквизитов у ключевых объектов, так как это наиболее важные доработки и проще начать именно с их выделения, но можно просто идти последовательно по метаданным или вообще начать с общих модулей).

3. Определяем ключевые слова:
   Имя реквизита/объектаМетаданных/функции/процедуры/переменной/элемента формы, выписываем в таблицу вида.

Можно изменять состав колонок по своему усмотрению или использовать не таблицу, а иные форматы.

4. Удаляем доработки из конфигурации.

5. Делаем глобальный поиск по выписанным ключевым словам для нахождения «связанных кусков». Повторяем пункты 1 — 5, пока не будут выписаны все ключевые слова и удалены все найденные по ним доработки, глобальный поиск по ключевым словам будет давать пустой результат.

6. Своими словами описываем, что делает эта доработка. Здесь могут помочь комментарии кода с ФИО сотрудника и указанием номера задачи в учетной системе, история хранилища, нетронутая копия базы, отладка.

7. Проанализировать актуальность доработки в контексте новой конфигурации.

8. Перенести доработку в новую конфигурацию.

Пример: вычленения доработок по новому реквизиту

1. Делаем сравнение с конфигурацией поставщика.

2. При сравнении конфигурации с конфигурацией поставщика видно, что у справочника «Контрагенты» добавлен реквизит булевого типа ЯвляетсяСтратегическимПартнером. Берем эту доработку для описания.

3. Начинаем заполнять таблицу.

4. Удаляем реквизит ЯвляетсяСтратегическимПартнером.

5. Делаем глобальный поиск по строке ЯвляетсяСтратегическимПартнером

На форме документа РасходнаяНакладная в процедуре УправлениеВидимостью нашлось одно упоминание ключевого слова.

//+ Иванов Иван Иванович 10.02.2014 З635924

Если ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Объект.Контрагент, ЯвляетсяСтратегическимПартнером) Тогда

Объект.ДополнительныйКонтрольСделкиПоСтратегическимПартнерам.Видимость = Истина;

Иначе

Объект.ДополнительныйКонтрольСделкиПоСтратегическимПартнерам.Видимость = Ложь;

КонецЕсли;

/- Иванов Иван Иванович 10.02.2014 З0005924

1. Перезапускаем сравнение с конфигурацией поставщика, оно стало неактуально после удаления реквизита.

2. Видим, что условие, из процедуры УправлениеВидимостью() формы документа РасходнаяНакладная не типовой, а ДополнительныйКонтрольСделкиПоСтратегическимПартнерам — это добавленная в РасходнуюНакладную табличная часть с одной колонкой Сотрудники.

3. Продолжаем заполнять таблицу. Добавляем новые объекты конфигурации и ключевое слово.

4. Удаляем код из процедура УправлениеВидимостью и ТЧ ДополнительныйКонтрольСделкиПоСтратегическимПартнерам.

5. Делаем глобальный поиск по новому ключевому слову ДополнительныйКонтрольСделкиПоСтратегическимПартнерам.

Продолжаем выполнять пункты 1— 5 до тех пор, пока глобальный поиск по ключевым полям дает результат.

После того, как будут выписаны и удалены все доработки.

6. Заполняем таблицу описанием доработки.

7. После того, как доработки будет описаны разработчиком в таблице, их можно начинать анализировать. Оценивается актуальность каждой из доработок. Возможно, некоторые уже устарели или не имеют смысла в новой конфигурации.

Проверяется, не была ли реализована подобная доработка или ее аналог в новой конфигурации. Результат анализа также заносится в таблицу, например:

8. Затем разработчик последовательно переносит необходимые доработки в новую конфигурацию. Так как конфигурации разные, и названия объектов метаданных могут различаться, переносить нужно аккуратно. Проверить новые источники данных и названия модулей или типовых процедур.

Необходимо проанализировать каждую доработку, как она будет работать в контексте новой конфигурации. Иногда доработку невозможно перенести один в один или с минимальными изменениями, и придется писать код с нуля.

В процессе переноса можно провести рефакторинг и оптимизацию кода. Очистить его от устаревших подходов разработки. Например, заменить ЭтаФорма на ЭтотОбъект, ЗначениеВСтрокуВнутр на ОбщегоНазначения, ЗначениеВСтрокуXML и т. п. Привести код к стандартам ИТС.

Таким образом, мы учли и перенесли все необходимые доработки при переезде на новую конфигурацию, исключив возможные ошибки.