Аудит доработанной конфигурации

В современном бизнесе системы 1С является одним из самых распространенных и эффективных инструментов для автоматизации учета и управления. Однако в процессе эксплуатации многие компании сталкиваются с проблемами сопровождения конфигураций:

- долгие обновления, которые откладываются из-за сложности;

- частые ошибки, причины которых трудно выявить;

- непонимание комплексности несоответствия собственной конфигурации типовому формату.

В этой статье рассмотрим важность проведения аудита основной конфигурации и порядок выполнения этого процесса.

1) Первой причиной необходимости в проведении аудита является отсутствие документации по доработкам. Часто компании применяют специфические изменения в конфигурации, но забывают или пренебрегают документированием этих изменений. Это может привести к сложностям в дальнейшем, когда потребуется изменять или модернизировать систему. Также отсутствие документации не позволяет понять, насколько на текущий момент база является изменённой.

2) Второй причиной является сложность в идентификации причин возникновения ошибок. Код и логика доработок могут быть сложными и запутанными, что затрудняет поиск и устранение ошибок. Бывает три вида причин, по которым возникают ошибки:

– неправильная работа пользователей в программе;

– ошибки, допущенные программистом при написании кода;

– ошибки, допущенные разработчиками конфигурации.

Из-за отсутствия документации и четкого описания доработок пользователи и разработчики могут тратить много времени на поиск причин возникновения ошибок и их исправления.

3) Третья причина – сложности в проведении обновлений. Часто после обновлений системы возникают ошибки, связанные с несовместимостью с доработками. Кроме того, некоторые обновления могут быть слишком долгими и дорогостоящими.

Проведение аудита доработок позволяет выявить и удалить ненужные или устаревшие доработки, что ускоряет процесс обновления и позволяет уменьшить количество потенциальных ошибок.

Теперь рассмотрим порядок проведения аудита и его основные этапы.

Первый этап – анализ конфигурации. Для этого используется стандартная функция конфигуратора - сравнение основной конфигурации с конфигурацией поставщика. Этот этап позволяет выявить все отличия конфигурации от типового формата.

Процесс анализа может значительно усложниться, если ранее конфигурация была некорректно обновлена. В этом случае в окне сравнения будут отображаться типовые модули, которые не дорабатывались. Это означает, что при обновлении конфигурации типовые модули не были обновлены – не удалён устаревший код и не добавлен тот код, который должен был прийти с обновлением.

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

Решением данной проблемы является процедура объединения основной конфигурации с конфигурацией поставщика. В ходе объединения имеет смысл оставлять все объекты, помеченные, как отсутствующие в конфигурации, чтобы не удалить те фрагменты кода, которые является нетиповыми.

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

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

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

Универсальных советов в проведении подобного рода анализа нет. Однако есть способ, который позволяет, отделить используемые изменения от тех, которые можно смело удалить. Этим способом является функции конфигуратора «Глобальный поиск» и «Поиск ссылок на объект».

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

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

Рисунок 1 - Окно настройки областей поиска ссылок

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

- Тип объекта метаданных – столбец с наименованием типа объекта, в котором выявлены расхождения, это может быть любой объект из дерева – «Документ», «Справочник» и т.д.

- Наименование обнаруженного объекта – это уже название конкретного элемента дерева, например, справочник «Сотрудники», документ «РеализацияТоваровУслуг», регистр сведений «УдалитьВложенияНеформализованныхДокументов» и т.д.

- Путь к объекту в режиме предприятия. Важный пункт, который поможет на следующем этапе. Необходимо прописать путь к объекту, если его возможно открыть в режиме «Предприятие» так, чтобы пользователи могли самостоятельно его найти. Это может быть ссылка или путь.

- Элемент объекта. Если в объекте изменён конкретный элемент – процедура, реквизит, элемент формы, то необходимо прописать название этого элемента. Если была изменена процедура, то название процедуры.

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

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

Будет не лишним разделить доработки по группам – разделить их на логичные категории, например, всё, что отвечает за формирование печатных форм, макетов и т.п., отнести в группу «Печать». Идея в том, чтобы распределить по группам все объекты, которые участвуют в логике процесса именно этой группы – это упростит и внесёт системность в понимание областей функций, которые затрагивают изменения в части бизнес-процессов компании.

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

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

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

Рисунок 2 – Рекомендации к первому этапу

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

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

Когда первая встреча прошла необходимо определиться с форматом проведения работ. Практика показала, что самым удобным вариантом является следующая схема:

1) Выделяется ряд доработок, которые пользователи должны будут проверить в режиме предприятия.

2) Сформировать для пользователей облегчённый вариант таблицы, где будут указаны пути к доработкам таким образом, чтобы пользователи могли самостоятельно их найти. В данной таблице при описании доработок необходимо максимально приблизиться к пользовательскому пониманию того, что необходимо проверить, следует инкапсулировать все технические описания процедур, команд и их связей в понятные пользователю термины.

3) Сформированную таблицу направить пользователям и назначить время следующей встречи.

4) В течении периода между встречами пользователи должны самостоятельно, насколько это возможно, проверить использование доработок в списке.

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

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

Если же доработка более комплексная и сложная, и одновременно с этим пользователи не могут определить её пригодность, то лучше принять решение о её сохранении. Во всяком случае, к этому списку всегда можно будет возвращаться и продолжать работу.

Рисунок 3 - Рекомендации ко второму этапу

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

Рисунок 4 - Рекомендации к третьему этапу

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

После того, как первичная проверка работы конфигурации была завершена, необходимо передать конфигурацию на проверку конечным пользователям, чтобы уже они подтвердили корректность работы конфигурации. Уже по окончанию этого этапа можно переходить на получившийся формат конфигурации, но есть ещё один очень важный этап, который необходимо выполнить.

Рисунок 5 - Рекомендации к четвёртому этапу

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

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

В ходе выполнения данного этапа необходимо расставлять комментарии, если был изменён программный код. Если были добавлены новые элементы – реквизиты или объекты метаданных, то очень важно добавлять специальный тег-идентификатор в название этого объекта, а в комментарии написать цель добавления этого объекта.

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

Рисунок 6 - Рекомендации к пятому этапу

В заключение можно с уверенностью сказать, что проведение аудита доработок конфигурации 1С является эффективной и важной частью процесса сопровождения. Эта работа позволяет выявить и устранить потенциальные проблемы и ошибки. Проведение аудита помогает оптимизировать процессы и упростить дальнейшее сопровождение конфигурации. Таким образом, инвестиции времени и ресурсов в проведение аудита с последующим применением рекомендаций окупаются, обеспечивая более стабильную и удобную работу с системой.

Рисунок 7 - Схема порядка проведения анализа доработок