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

Когда много лет назад я начал работать в экосистеме Salesforce, одной из самых влиятельных книг, которые я читал в то время, была книга Дэна Эпплмана Advanced Apex Programming. В частности, его объект Debug Info и шаблон ведения журнала действительно нашли отклик у меня, так как он решил критическую проблему для разработчиков, связанную с отсутствием доступной информации журнала при возникновении ошибки. Сообщения об ошибках Apex содержали только исключение и трассировку стека, но не содержали информации о состоянии приложения на тот момент. И в большинстве случаев ошибка происходила без включения журналов отладки, поэтому у разработчиков никогда не было ничего ценного, с чего можно было бы начать расследование.

Я использовал эту концепцию несколько раз на протяжении многих лет и могу только повторить, насколько она великолепна. Например, во время комплексного развертывания проекта, переводящего всю организацию на использование Salesforce с одного дня на другой, наша проектная группа смогла выявить и устранить проблемы интеграции с различными приложениями от более 200 ошибок в первый день до менее 50 ошибок. менее чем за 3 дня. Это было возможно только потому, что у нашей команды была подробная информация об ошибках, в том числе важная информация о полезной нагрузке, отправленной в другие системы, и вся эта информация была доступна в Salesforce.

Сегодня, незадолго до выхода версии Winter 20, Salesforce изменила свою модель разработки. Благодаря компонентам Lightning, а теперь и веб-компонентам Lightning, все больше и больше бизнес-логики перемещается из Apex на стороне сервера в Javascript на стороне клиента. К сожалению, с этим сдвигом отладка снова стала намного сложнее. Если вы работали с фреймворками, вы, вероятно, заметили, что технические детали окон ошибок очень технические и не предоставляют много информации о том, что делал пользователь и что происходило внутри вашего компонента в это время. И если вы хотите просматривать свои журналы отладки на консоли, вам нужно получить доступ либо в качестве браузера пользователя, либо поручить им запустить диагностику для вас.

Я мог бы продолжить рассказ о трудностях решения проблем внутри компонентов Lightning, но я уверен, что вы все понимаете (или знаете) ту боль, которую я пытался объяснить.

Чтобы решить эту проблему, я решил сесть и попытаться распространить концепцию отладки Appleman на Lightning Components, что привело к выпуску Reliability Force, небольшой библиотеки Salesforce, состоящей из Lightning Components, Lightning Web Components и кода Apex, который призван помочь разработчикам встроить надежную диагностику в свой код. Вы найдете платформу ведения журналов, способную отправлять отчеты журнала на сервер, где они могут быть обработаны с использованием других функций платформы, т. е. сохранены в пользовательском объекте или отправлены по электронной почте в список ошибок Apex. Я также добавил платформу триггеров на основе пользовательских метаданных, которая использует версию платформы ведения журналов Apex, чтобы гарантировать, что любые ошибки будут правильно фиксироваться и сообщаться. И последнее, но не менее важное: поведение фреймворка ведения журналов определяется с помощью пользовательских настроек, которые позволяют вам определять стандарты для вашей организации, а также предоставлять исключения для отдельных пользователей для получения дополнительных сведений об этих группах.

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

Пожалуйста, проверьте репозиторий Github и дайте мне знать, что вы думаете: https://github.com/j-fischer/rflib

Спасибо!

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