Простой контрольный список для хорошей проверки кода
Привет, я недавно закончил магистратуру и, несмотря на двухлетний опыт работы, начал серьезно проверять код только в течение последних 7 месяцев на моей новой работе.
Будучи младшим разработчиком программного обеспечения, я всегда боролся с рецензированием кода, потому что «боялся» старших разработчиков. Мы никогда не учимся делать обзор кода в школе, поэтому я поискал в Интернете руководства и советы для хорошего обзора. Я нашел много веб-сайтов, но ни на одном из них не было четкого и простого контрольного списка. В этой статье предпринята попытка собрать информацию, собранную с нескольких веб-сайтов, в простой контрольный список, который вы можете использовать при просмотре кода коллег.
Во-первых, позвольте мне немного рассказать о почему мне нравится делать обзоры кода (я считаю, что многим разработчикам это не нравится) и почему я считаю их важными. Когда я начал свою новую работу, я был поражен технологиями, используемыми в проекте, и кодовой базой проекта. Я впервые использовал несколько технологий, и у меня был довольно большой технический долг. Вдобавок к этому у проекта есть масса нюансов с деловой стороны. Единственное, что ускорило мое понимание проекта, - это проверка кода! Когда я просматривал код, я мог понимать небольшие фрагменты кода (функции) вместо того, чтобы пытаться понять весь проект сразу. Это было намного проще, и по каждой функции (запрос на вытягивание за запросом на вытягивание) я должен лучше понимать проект и сам код. Из-за этого я теперь люблю проверять код! Теперь я просматриваю каждый запрос на перенос, который входит в кодовую базу, потому что я действительно хочу понять все маленькие части, которые вместе составляют проект.
Конечно, есть много других преимуществ проверки кода. Но, как следует из названия, это простая статья, поэтому давайте оставим ее простой и понятной :)
Контрольный список:
✓ Обрабатывает ли код крайние случаи?
✓ Вы видите дублированный код? Можно ли абстрагировать этот код?
✓ Есть ли способ сделать код короче / проще / быстрее и т. д.?
✓ Трудно ли понять код? А что с названиями, они понятны? Комментарии в коде хорошо продуманы?
✓ Все переменные и методы названы правильно?
✓ Все новые переменные объявляются?
✓ Добавляет ли изменение время выполнения или вызывает проблемы с производительностью?
✓ Все ли параметры определены правильно и имеют правильный тип?
✓ Хорошо ли импортированы библиотеки? Мы используем устаревшие методы?
✓ Соответствует ли код стандартам проекта и соглашениям об именах?
✓ Тон моих комментариев положительный и не повредит другим чувствам разработчиков?
✓ Могу ли я в своих комментариях не отдавать приказы, а вместо этого давать предложения? («Измените этот метод на xxxx» vs « Что вы думаете об изменении этого метода на xxxx?»)
✓ Я критикую код, а не автора? («Почему ВЫ….?» против «В чем причина этого…»)
Надеюсь, вы найдете это полезным :) вы можете использовать этот контрольный список всякий раз, когда просматриваете код. Если у вас есть другие предложения, добавьте их в комментарий.
Давайте сделаем обзоры лучше, начнем им нравиться и, в конце концов, будем строить отличные проекты :)
