Как быть лучше при просмотре кода?

Сначала я твердо верю в процесс проверки кода и всегда хочу, чтобы кто-то еще проверял мой код. Мой вопрос действительно сводится к тому, как я могу лучше выполнять проверку кода для кого-то еще?

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

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

Обычно я следую

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Я думаю, что вы многое можете добавить к этому.

спросите себя, что делает других хорошим рецензентом для вас?

также, как вы проходите через код;

• остановись на чем-то, чего ты не понимаешь сейчас напиши что нужен комментарий
• определить, соответствует ли оно стандартам кодирования: пробелы, скобки, camelCase..etc
• проверьте, что он включает в себя все функции
• сделать простое тестирование логики, чтобы увидеть, проходит ли она граничные условия и т. д.

Я просто стремлюсь к

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

Кроме того, «зная, что искать» просто приходит с опытом, практикой и чтением.

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

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

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

Я настоящий поклонник обзоров кода, если они соответствуют следующим оценкам:

• каждый разработчик имеет возможность пересмотреть весь код и аргументировать свое мнение
• никто не имеет права злоупотреблять чужим кодом
• не только плохой код активирует обсуждение, но и хороший код тоже
• обсуждение заканчивается счастьем для всех вовлеченных людей
• обзор происходит почти в режиме реального времени, по крайней мере, до завершения функции

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

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

• есть ли проблемы, связанные с безопасностью
• предназначены API, используемые
• применил ли код указанную архитектуру
• он написал полезные тесты (но только если он был проинструктирован, я должен был учиться)
• Документация
• строить-процесс
• ... и еще немного, вероятно

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

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

[H] Как я могу лучше выполнять проверку кода для кого-то еще?

Задайте им много вопросов

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

На самом деле, нет, вам не нужно знать код заранее, чтобы быть хорошим рецензентом.

Пару рабочих мест назад мой работодатель начал требовать, чтобы все проверки кода были подписаны рецензентом. Я делал в основном работу с графическим интерфейсом в Си, и одним из лучших рецензентов для меня был мой приятель Билл. Он был опытным в C, но никогда не делал много работы с GUI, и, изучая обзоры, он не знал, как должен работать мой код.

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

Несмотря на то, что я там больше не работаю, я все еще проверяю различия перед регистрацией и спрашиваю себя: «Какие вопросы у Билла по этому поводу?» И довольно часто я в результате чего-то меняю.