Контрольный список отладчика

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

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

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

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

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

Работает на Моей машине

Если это не воспроизводится локально, вы можете использовать удаленную отладку. Это довольно просто для большинства современных инструментов разработки, например эта статья описывает процесс удаленной отладки Java-процесса в IntelliJ/IDEA. Вы можете применить тот же метод к большинству IDE и языков/платформ.

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

Без этого вы можете попробовать следующие приемы:

Запускайте локально, но подключайтесь к удаленной базе данных – обычно я просто использую SSH-туннелирование но я слышу хорошие вещи о Телепортация
Запишите точные учетные данные точки входа, отправленные пользователем, и попытайтесь воспроизвести запрос локально

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

Если Ошибка несовместима

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

Случается редко
Никогда не произойдет, если мы остановимся на точке останова

В обоих случаях лучшим решением является ведение журнала, и да, ведение журнала – это форма отладки… Мы можем добавить журнал, “Применить изменения кода” (или отредактировать и продолжить) и мгновенно увидеть результаты в наших журналах.

Если проблема не возникает, когда у нас есть точка останова, вполне возможно, что она может не воспроизводиться даже с помощью журнала. Это потому, что проблема связана с потоковой передачей. Отладка состояния гонки или тупика на самом деле не так болезненна, как это иногда представляется. Я расскажу об этом немного позже в этом посте. Обратите внимание, что отладка – это “легкая часть”, ее исправление… Это самая трудная часть…

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

public class DebugUtil {
  public static String stackHash() {
    try {
      // code from https://www.baeldung.com/java-stacktrace-to-string
      StringWriter sw = new StringWriter();
      PrintWriter pw = new PrintWriter(sw);
      new RuntimeException().printStackTrace(pw);

      // checksum for speed
      int sum = 0;
      for(char c : pw.toString().toCharArray()) {
        sum += (int)c;
      }
      return Integer.toHexString(sum);
    } catch(IOException err) {
      return "Invalid Stack";
    }
  }  
}

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

Условные Точки останова

Вы, вероятно, знаете об условных точках останова, но когда вы в последний раз их использовали?

Если это недавно, то слава вам! Ты один из немногих избранных.

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

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

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

Промыть Повторить

Вам знакомо это чувство, когда вы переступаете через код, потратив целую вечность на то, чтобы все сделать правильно… Когда вы заходите слишком далеко и “упускаете это”! Это самое неприятное чувство… Это вызывает у вас желание закатить истерику.

Что ж, есть решение. Мы все должны знать о “run to cursor”, что очень приятно. Но большинство IDE также поддерживают Go to Cursor, который позволяет вам манипулировать указателем инструкции и возвращать выполнение назад (или перемещать его вперед) в произвольное (законное) местоположение.

Как ни странно, до недавнего времени это не поддерживалось в IntelliJ. Это все еще не так… Но есть плагин!

Плагин jump to line – один из тех немногих обязательных плагинов для IntelliJ, который полезен практически всем. Это спасает жизнь и повышает уровень счастья. С помощью этого плагина вы можете буквально перетащить стрелку выполнения слева в новое место… Удивительный.

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

продолжение следует

В следующий раз я расскажу о процессе отладки приложения. Это очень простой процесс, но, как обычно, “дьявол кроется в деталях”.

Есть ли у вас свой собственный процесс?

Я бы с удовольствием выслушал ваши мысли и советы/рекомендации по отладке.

Оригинал: “https://dev.to/codenameone/the-debugger-checklist-part-i-3dco”