Протоколирование сложных алгоритмов для пользователя

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

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

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

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

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

Когда я работал с ЗУП, то видел там замечательный механизм - выполнить расчет по сотруднику с комментарием. В комментарии выдавались подробности расчета. Но, видимо, 1с не хотело напрягать пользователей, и комментарии были очень поверхностными, иногда все-таки приходилось брать отладчик или смотреть промежуточные отчеты для того, чтобы понять, почему считает так или иначе.

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

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

Чтобы протоколирование не влияло на производительность, нужно включать его только тогда, когда требуется анализ, ну примерно как это сделано в 1С:ЗУП, где можно рассчитать зарплату по сотруднику без комментария или с комментарием. Однако на практике удобнее включать комментирование по выделенным строкам. Т.е. выделилил строки, нажали кнопку обработки - с комментарием или без. Потом можно смотреть протоколы.

Такой протокол в программировании называется трассировка. И он очень полезен. Я предлагал 1С в ЗУП внедрить протоколирование начислений налогов и прочих участков, которые для пользователей пока выглядят как черные ящики, но пока что не был услышан.

Пару рекомендаций:

· В протоколе указывайте, что именно протоколируется - документ или номер строки.

· Можно использовать не только окно сообщений, но и табличные документы

· Ошибки отделяйте от информационных сообщений, выделяя их жирным или красным цветом

· Протокол неплохо сохранять в отдельном поле документа, но не как текст, а как список важных тегов, т.е. что именно происходило с данной строкой.

Ну, и напоследок, приведу пример протокола.

Я конвертирую одни счета в другие. В документе в строке содержится исходный счет дебета и кредита и аналитика.

Протокол сообщает о том, какие счета получены в результате и какие правила конвертации применены.

Вот так выглядит протокол:

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

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

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

Тоже очень удобный метод. Рекомендую.