Что является полезным для мышления при проведении формальной проверки кода

Наша команда недавно начала проводить проверки кода на предмет каждой регистрации.

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

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

Имейте в виду общие цели: в конце концов, только рабочее программное обеспечение имеет значение

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

Установите четкую область для вашего обзора

Имейте в виду: это не ваш код, а код команды. Итак, сосредоточьтесь на вещах, которые могут привести к неправильным результатам.

• Не оспаривайте способ, которым ваш разработчик решил удовлетворить требования, если вы не уверены, что он не будет работать (но он уже должен был провалить тесты, нет?)

• Не бросайте вызов плохой производительности, если нет меры, которая показывает, где проблема. Преждевременная оптимизация - корень всего зла ;-)

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

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

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

Развитие лидерства: человеческая сторона обзора

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

• Обзоры кода гораздо приятнее для всех, если есть настоящий обмен. Дайте вашему разработчику возможность также показать свои навыки (и да, возможно, вы могли бы узнать что-то новое).
• Открыто слушайте критику по поводу выбора дизайна или существующих стандартов. Иногда люди могут лучше справляться с такими разочарованиями только потому, что они могут говорить об этом.
• Тренируйте своих юниоров: не стесняйтесь давать советы или рефакторинг ориентации для следующей итерации. Не делайте этого со старшими: в другом мире ваша роль могла бы поменяться.

Воспользуйтесь преимуществами других практик

Есть несколько вещей, которые вы можете избежать в обзоре кода:

• Использование статического анализатора кода в цепочке сборки может автоматизировать обнаружение распространенных ошибок или непереносимых конструкций задолго до экспертной оценки. Некоторые инструменты могут даже проверить некоторые из ваших стандартов кодирования .
• Если у вас есть стандарты в отношении разметки кода, используйте форматирование pre-commit pretty-print или аналогичные для форматирования кода, как требуется автоматически. Никогда не тратьте время на то, что программное обеспечение может сделать для вас лучше и без обсуждения :-)
• Наконец, качество обеспечивается не только обзором, но и тестами. Если вы еще не используете TDD , подумайте об этом независимо от проверки кода.

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

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

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

Здесь субъективный подход. Объективный подход, ИМО, очень хорошо объяснен в этом вопросе .

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

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

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

Вмешательство кода разработчика в косметические изменения демотивирует разработчика, но в абсолютных обстоятельствах это необходимо сделать. Ведущий должен найти баланс между предоставлением полезного обзора кода и обучением, чтобы избавиться от незначительных недостатков. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Некоторые вещи, которые нужно иметь в виду:

1. Это касается как психологии, так и технологии, поэтому здесь нет золотого правила.
2. Что касается людей, это не только знания, но и культура и положение в иерархии.
3. Если это «длинная» игра (стабильная и устоявшаяся компания), то хорошо интегрированная команда, в которой люди доверяют друг другу, обычно имеет большую ценность, чем рассматриваемый код. Это не должно использоваться, чтобы заставить вещи, которые не абсолютно необходимы, чтобы продолжить. Дьявол кроется в деталях ...
4. Если это «короткая» игра (сторонний проект, исследования и разработки, много фрилансеров в группе), то затраты на CR часто преодолевают преимущества, возникающие при их выполнении. И отношение должно быть "просто зажги"

Есть только две вещи, которые имеют значение.

1. Есть ли автоматизированные тесты для всех требований?
2. Они все проходят?

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

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

Требования хороши? Что в идеале вы должны знать перед началом задачи, т.е. производительность, безопасность и т. Д.

Являются ли тесты хорошими тестами? Любые пропущенные крайние случаи, хорошо ли они тестируют требование и т. Д. В конечном счете: Можете ли вы написать тест, который соответствует существующему требованию, но не даст результатов?