Как подготовиться к просмотру кода

Question

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

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

Есть ли лучшая методология для анализа кода? Использование диаграмм?

Или мне просто нужно работать над тем, как я объясняю свои изменения.

Answer 1

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

Answer 2

Я предпочитаю git или svn историю совершений. Легко проанализировать, что именно и в каком порядке кто-то сделал.

Answer 3

Что вы сделали, абсолютно не нужно, более чем неадекватные комментарии могут добавить шум в поток кода. Если рецензент хочет увидеть, что было сделано, он будет использовать историю VCS для сравнения с первоначальной версией. Но ваше требование - создать чистый и простой код, который работает правильно. Вы должны следовать соглашениям об именах Java, чтобы использовать согласованные имена для ваших переменных и объектов, комментарии должны быть о том, что делает код, а не то, что вы сделали в коде, отформатируйте код, поэтому он правильно отступил от строк. Написание комментариев Javadoc к общедоступным методам является обязательным, комментарии к закрытым и защищенным методам являются необязательными. Качество комментариев к ценной информации в нем умножает важность кода как минимум на десять, помните об этом. Лучше, если вы используете некоторые проверки или инструменты для отслеживания ошибок, чтобы сообщать обо всех возможных ошибках даже в компилируемом и проверенном рабочем коде. Эти инструменты способны находить скрытые ошибки, которые вы не видите в коде невооруженным глазом.

Answer 4

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

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

1. Он знает о бизнес-логике вы изменили код, чтобы он мог сосредоточиться на нем тоже в дополнении к технической части (обработка ресурсов/масштабируемость/стиль и стиль работы/кодирования в вашей компании/формирование).
2. Он не имеет понятия об этом/или изменения носят чисто технический характер, и он может сосредоточиться только на этой части, так что в конце он может сказать: «Я не знаю, что делает код, но он мне кажется разумным».

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

Затем создайте набор изменений, в котором вы можете легко увидеть изменения, внесенные в каждый файл (с использованием diff), объясняя, почему вы изменили каждую часть (изменение/рефакторинг/оптимизация/подпись метода/поле, метод или класс добавлены или удалены и т.п.)

Хорошая стратегия, чтобы пройти все изменения, - это начать, где начинается фактическая обработка и идти к ее концу.

Из Кур, если у вас есть построить некоторый новый модуль это все дни хорошая идея иметь диаграммы (диаграммы классов, активность, последовательность и т.д.)