Зона наблюдения и рендереры: все, что вам нужно знать
11 января 2023 г.Вот оно. книга по отладке запущена. Буду очень признателен за отзывы и отзывы!
Я также закончил записывать и редактировать весь курс. Всего 50 видео общей продолжительностью 7 часов... Я также записал дополнительные видео для двух других бесплатных курсов для для начинающих и для современной Java. Так что следите за ними.
Визуализаторы
В сегодняшнем видео мы обсудим одну из моих любимых малоизвестных функций IDE: средства визуализации. О них знают очень немногие. Я объяснял их в прошлом, но я чувствую, что не объяснил должным образом, почему они намного лучше, чем любая другая альтернатива.
На этот раз, я думаю, я правильно понял объяснение. Если вы работаете с JPA или любым сложным API, вам следует это проверить, я думаю, что демо-версия революционна. Если вы предоставляете разработчикам сложную библиотеку, это также может быть прекрасным инструментом.
https://www.youtube.com/watch?v=oaUf8KXHsd0?embedable=true
Расшифровка
Добро пожаловать обратно в шестую часть отладки в масштабе, где ошибки умирают.
В этом разделе мы обсуждаем область наблюдения. Часы — одна из самых важных областей в процессе отладки.
Тем не менее, мы не уделяем этому столько внимания, сколько должны. В этом сегменте мы обсудим несколько мощных вещей, которые мы можем сделать в области просмотра, и как мы можем расширить ее, чтобы поддерживать некоторые фантастические возможности.
Отключить визуализаторы
Начнем с отключенных визуализаторов, которые позволяют повысить производительность области наблюдения. Прежде чем мы обсудим это, я хотел бы поговорить о самой зоне наблюдения. Это зона наблюдения. В нем мы можем видеть большинство видимых переменных для текущего кадра стека и их значения.
Мы можем расширить записи в зоне наблюдения. Каждое значение переменной или выражение, которое у нас есть в часах, является записью. Мы можем добавлять к часам произвольные элементы и даже встраивать выражения часов непосредственно в пользовательский интерфейс IDE.
Обратите внимание на значения справа, обычно это результаты метода toString(). В IntelliJ мы можем настроить их с помощью средств визуализации, которые мы обсудим далее. Но это еще не все, как мы увидим позже.
А пока просто подумайте об этом. Каждый раз, когда я перехожу строку кода, среда IDE должна собирать все переменные в области видимости и вызывать toString() для каждой из них. В некоторых случаях даже более сложный код. Это дорого и медленно…
В контекстном меню у нас есть опция отключения звука рендереров. Установив этот флажок, мы можем отключить это поведение и потенциально значительно увеличить скорость перехода. Как только мы выберем это, вы заметите, что все значения превращаются в три точки, за которыми следует слово toString.
Это означает, что рендереры больше не извлекают значение. Вместо этого они показывают этот заполнитель. Это полностью устраняет накладные расходы средств визуализации и может повысить производительность пошагового перехода.
Если мы хотим увидеть значение, мы можем щелкнуть метку toString, и значение будет извлечено динамически. Обратите внимание, что это влияет только на объекты. Эта функция не затрагивает примитивы, массивы и т. д.
Настроить визуализацию
Визуализация – это процесс отображения значений элементов в часах. Чтобы начать работу с рендерерами, нам нужно настроить их через контекстное меню здесь. Это запускает диалоговое окно настройки рендерера, которое позволяет нам делать удивительные вещи в IntelliJ.
Для самой базовой настройки мы можем переключать и включать несколько функций в этом диалоговом окне. Затем нажмите «Применить», чтобы мгновенно увидеть их в представлении переменных ниже. Я вижу объявленный тип поля.
Мы можем включать полные имена для файлов классов, чтобы мы могли видеть значения статических полей. Мы можем включать шестнадцатеричные значения для примитивов по умолчанию, и это функция, которую я всегда включаю, потому что она очень полезна для меня.
Это потрясающее представление, которое стоит изучить и настроить в соответствии со своими предпочтениями, где вы можете настроить уровень детализации в области просмотра.
Но настоящая сила этого диалога во второй вкладке. Средство визуализации типа Java, которое является следующей темой.
Визуализация данных
С помощью средств визуализации мы можем пойти гораздо дальше. Возможно, вы помните объекты посещения, которые я показывал ранее. Это из стандартной демонстрации Spring Boot под названием Pet Clinic. Spring Boot имеет концепцию репозитория, который представляет собой интерфейс, представляющий источник данных.
Часто репозиторий — это просто таблица, он может делать больше, но он тесно связан с лежащей в его основе таблицей SQL, и это помогает рассматривать его в этих терминах.
Если вы посмотрите на объекты visitRepository и perRepository в нижней части экрана, вы заметите, что нам нечего делать.
Это просто идентификаторы объектов без данных, которые могут быть ценными для человека, занимающегося отладкой объектов. Я их не расширял, но и под переменными здесь ничего нет.
Давайте исправим это в представлении настройки данных, как мы делали раньше.
Мы добавляем средство визуализации, которое применяется к JpaRepository, который является базовым интерфейсом этого экземпляра. Затем мы просто пишем выражение для представления рендеринга здесь. Этот модуль визуализации будет применяться к репозиторию JPA и его подчиненным интерфейсам или классам.
Затем, вместо использования средства визуализации по умолчанию, я использую выражение, чтобы указать, что мы будем показывать. JPARepository включает метод с именем count(), который запрашивает базу данных и подсчитывает количество элементов в базе данных.
Я просто вызываю его и замечаю, что предполагаю, что текущий объект — это отображаемый объект. Я не предоставляю экземпляр объекта. IDE автоматически запускается в контексте объекта. Вы также можете использовать this для представления отображаемого объекта. Обратите внимание, что мне не нужно выполнять приведение к JPARepository.
Это означает, что выражение будет отображаться непосредственно в часах без изменения метода toString, который в данном случае я, очевидно, не могу изменить и, как правило, не хочу. Метод toString() полезен в производственной среде; Я бы не хотел, чтобы там был дорогой код.
Но в рендерере я могу просто сходить с ума и делать то, что не имеет смысла в репозитории. Обратите внимание на флажок по требованию. Если мы отметим это, выражение по умолчанию будет действовать как приглушенный рендерер. Вам нужно будет щелкнуть его, чтобы увидеть значение.
Давайте применим это изменение к коду, и вы заметите, что visitRepository мгновенно изменится, чтобы использовать новое выражение, которое мы определили. Теперь мы можем сразу увидеть, что репозиторий имеет 4 элемента, что довольно круто. Верно?
Обратите внимание, что petRepository не изменился; это потому, что это тоже репозиторий, но не JPARepository.
До сих пор мы делали то, что теоретически можно сделать с помощью методов toString(). Это может быть хакерским, но это не что-то уникальное. Давайте поднимем это на ступеньку выше.
Параметр «При расширении узла» позволяет нам определить поведение, когда пользователь расширяет запись. Метод findAll() класса JPARepository возвращает все объекты в репозитории; это будет вызвано, когда мы расширим запись.
При желании мы можем проверить, есть ли причина показывать виджет расширения. В этом случае я использую метод count(), который будет быстрее, чем повторный вызов findAll(). После применения изменений мы можем увидеть перечисленные элементы из репозитория.
Вы заметите, что здесь присутствуют все 4 элемента, и, поскольку они являются объектами, мы можем видеть все атрибуты, как и любой объект, который мы видим в часах.
Это действительно впечатляюще, и вы не можете подделать его вызовом toString()…
Делаем для всех
Это была крутая функция, верно? Но так утомительно настраивать все это для каждого проекта. Здесь мы видим тот же рендерер, что и раньше, вы заметите, что все выглядит точно так же.
Нумерация, список сущностей и т. д. Но когда мы открываем список рендереров, он пустой; рендереров нет!
Как это вдруг работает без рендерера?
Что происходит?
Мы используем аннотации кода для представления средства визуализации.
Таким образом, вы можете зафиксировать средство визуализации в репозитории проекта, и вам не нужно настраивать отдельные экземпляры IDE. Это довольно просто: мы добавляем зависимость от библиотеки аннотаций JetBrains в POM.
Это библиотека аннотаций. Это означает, что код существенно не меняется. Это просто маркеры. Поскольку это всего лишь подсказка для отладчика, во время выполнения она игнорируется и не влечет за собой каких-либо последствий или накладных расходов.
Мы добавляем импорт в средство визуализации, затем прокручиваем вниз и добавляем простой код аннотации средства визуализации. Обратите внимание, что это почти тот же код, который я набрал в диалоговом окне, но на этот раз он используется в аннотации.
Таким образом, вся наша команда сможет воспользоваться улучшенным представлением объектов репозитория!
Если вы создаете библиотеки или платформы, вы можете интегрировать это, чтобы упростить процесс отладки для ваших пользователей, не влияя на поведение методов toString() или аналогичную семантику.
Наконец-то
В следующей статье мы обсудим вопросы потоковой передачи. Их репутация «сложных в отладке» не всегда оправдана.
Если у вас есть какие-либо вопросы, пожалуйста, используйте раздел комментариев. Спасибо!
Оригинал