Очень часто, когда используются сложные алгоритмы или запутанные схемы, только программист может разобраться, почему сработала та или иная ветка алгортима.
Поэтому пользователи звонят программисту, он берет в руки отладчик, и начинает разбираться.
Предлагаю избавить себя от груза подобной ответственности. Выход прост - трассировать логику работы схемы, выдавать протокол.
Тогда пользователи научатся анализировать протокол, и будут обращаться только в действительно непонятных случаях, связанными с ошибками программы.
Когда я работал с ЗУП, то видел там замечательный механизм - выполнить расчет по сотруднику с комментарием. В комментарии выдавались подробности расчета. Но, видимо, 1с не хотело напрягать пользователей, и комментарии были очень поверхностными, иногда все-таки приходилось брать отладчик или смотреть промежуточные отчеты для того, чтобы понять, почему считает так или иначе.
Еще один пример - права доступа. Порой очень сложно понять, почему та или иная кнопка не доступна. Однако, если есть протокол назначения прав доступа (например, нажали кнопочку и выдался протокол, где расписано, как сработало назначение прав на этот документ), то все упрощается.
В результате длительной практики у меня сложилось мнение, что протокол работы схемы - лучший друг программиста. Причем протокол должен быть максимально подробным, по сути, каждая ветка если должна находить свое отражение в протоколе.
Чтобы протоколирование не влияло на производительность, нужно включать его только тогда, когда требуется анализ, ну примерно как это сделано в 1С:ЗУП, где можно рассчитать зарплату по сотруднику без комментария или с комментарием. Однако на практике удобнее включать комментирование по выделенным строкам. Т.е. выделилил строки, нажали кнопку обработки - с комментарием или без. Потом можно смотреть протоколы.
Такой протокол в программировании называется трассировка. И он очень полезен. Я предлагал 1С в ЗУП внедрить протоколирование начислений налогов и прочих участков, которые для пользователей пока выглядят как черные ящики, но пока что не был услышан.
Пару рекомендаций:
· В протоколе указывайте, что именно протоколируется - документ или номер строки.
· Можно использовать не только окно сообщений, но и табличные документы
· Ошибки отделяйте от информационных сообщений, выделяя их жирным или красным цветом
· Протокол неплохо сохранять в отдельном поле документа, но не как текст, а как список важных тегов, т.е. что именно происходило с данной строкой.
Ну, и напоследок, приведу пример протокола.
Я конвертирую одни счета в другие. В документе в строке содержится исходный счет дебета и кредита и аналитика.
Протокол сообщает о том, какие счета получены в результате и какие правила конвертации применены.
В некоторых случаях вместо протокола можно выводить промежуточные таблицы значений на разных этапах вычислений.Я внедрял такой метод в ЗУП, где при включенном в параметрах сеанса пользователя режиме отладки выводил промежуточные таблицы, т.е. выгружал результат запросов ЗУП при расчете налогов в таблицы значений, и стандартной функцией печати ТЗ выводил ее в макет.
Такой же метод я внедрял и в своих нетиповых конфигурациях на поддержке. Обычно в отчетах у меня стояла галочка "Выводить отладочные таблицы", которая выводила в ТЗ все запросы, из которых собирался отчет. При желании эти таблицы можно было сохранить в Excel, и проанализировать, чтобы проверить правильность работы отчета.
Тоже очень удобный метод. Рекомендую.
Пример протокола на картинке к статье.
