Является ли проверка кода субъективной или объективной (поддающейся количественной оценке)?

Я собираю некоторые руководящие принципы для обзоров кода. У нас пока нет одного формального процесса, и мы пытаемся его формализовать. И наша команда географически распределена.

Мы используем TFS для контроля исходного кода (мы также использовали его для задач / отслеживания ошибок / управления проектами, но мы перенесли это в JIRA ) с Visual Studio 2008 для разработки.

Что вы ищете, когда делаете обзор кода?

• Это то, что я придумал
  1. Принудительно FXCop правила (мы магазин Microsoft)
  2. Проверьте производительность (какие-либо инструменты?) И безопасность (подумайте об использовании OWASP - сканера кода ) и безопасность потоков
  3. Придерживайтесь соглашений об именах
  4. Код должен охватывать граничные случаи и граничные условия
  5. Должны правильно обрабатывать исключения (не глотать исключения)
  6. Проверьте, дублирована ли функциональность в другом месте
  7. Тело метода должно быть небольшим (20-30 строк), а методы должны выполнять одно и только одно (без побочных эффектов и избегать временной связи -)
  8. Не передавать / возвращать нули в методах
  9. Избегайте мертвого кода
  10. Документирование открытых и защищенных методов / свойств / переменных

Какие еще вещи мы должны обычно высматривать?

Я пытаюсь понять, можем ли мы дать количественную оценку процессу проверки (он будет давать идентичный результат при проверке разными людьми). Пример: сказать, что «тело метода должно содержать не более 20-30 строк кода», а не «метод». тело должно быть маленьким ".

Или обзор кода очень субъективен (и будет отличаться от одного рецензента к другому)?

Цель состоит в том, чтобы иметь систему маркировки (скажем, -1 балл за каждое нарушение правила FxCop, -2 балла за несоблюдение соглашений об именах, 2 балла за рефакторинг и т. Д.), Чтобы разработчики были более осторожны при проверке своего кода. Таким образом, мы можем определить разработчиков, которые постоянно пишут хороший / плохой код. Цель состоит в том, чтобы рецензент потратил максимум 30 минут на проверку (я знаю, что это субъективно, учитывая тот факт, что ревизия / ревизия может включать несколько файлов / огромные изменения в существующей архитектуре и т. Д., Но вы получаете общая идея, рецензент не должен тратить дни на просмотр чьего-либо кода).

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

Ссылка на книгу: Чистый код: руководство по гибкому программному мастерству Роберта Мартина .

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

Некоторые объективные исследования (Фаган и т. Д.) И многие распространенные мнения свидетельствуют о том, что взаимоотношения со сверстниками облегчают анализ кода, направленный на уменьшение ошибок и повышение производительности. Работающие менеджеры могут участвовать как работники, но не как менеджеры. Обсуждаются вопросы для обсуждения, изменения для удовлетворения рецензентов, как правило, полезны, но не обязательны Отсюда и отношения со сверстниками.

Любые автоматические инструменты , которые могут быть приняты без дальнейшего анализа или решений хороши - ворсинки в C, C ++, Java. Регулярная компиляция. Компиляторы ДЕЙСТВИТЕЛЬНО хороши в поиске ошибок компилятора. Документирование отклонений в автоматических проверках звучит как тонкий обвинительный акт автоматических проверок. Директивы кода (как в Java), допускающие отклонения, довольно опасны, ИМХО. Отлично подходит для отладки, чтобы вы могли быстро понять суть дела. Не очень хорошо найти в плохо документированном блоке кода в 50 000 строк без комментариев, за который вы несете ответственность.

Некоторые правила глупы, но легко применяются; например, по умолчанию для каждого оператора switch, даже если он недоступен. Тогда это просто флажок, и вам не нужно тратить время и деньги на тестирование со значениями, которые ничего не соответствуют. Если у вас есть правила , вы будете иметь глупость , они неразрывно связаны . Преимущество любого правила должно стоить глупости, которую оно стоит, и эти отношения должны проверяться через регулярные промежутки времени.

С другой стороны, «Это работает» не является добродетелью перед проверкой или защитой при рассмотрении. Если разработка проводилась по модели водопада , вы хотели бы выполнить обзор, когда кодирование завершено на 85%, до того, как сложные ошибки будут обнаружены и устранены, потому что обзор - более дешевый способ их обнаружения. Так как реальная жизнь не модель водопада, когда пересматривать это своего рода искусство и составляет социальную норму. Люди, которые на самом деле будут читать ваш код и искать в нем проблемы, - чистое золото. Управление, которое поддерживает это на постоянной основе, является жемчужиной выше цены. Отзывы должны быть как чекины - рано и часто .

Я нашел эти вещи полезными:

1) Нет стиля войн . Куда идут открытые фигурные скобки, должна быть только проверка согласованности в данном файле. Все так же. Это нормально тогда. То же глубина вдавливания ** s и ** вкладка ширины . Большинство организаций обнаруживают, что им нужен общий стандарт для табуляции, который используется как большое пространство.

2) Рваный

   looking

текст, который не

   line up is hard to read 

для содержания.

Кстати, K & R выделены пятью (ПЯТЬ) пробелами, поэтому апелляции к авторитету бесполезны. Просто будь последовательным.

3) Пронумерованная, неизменяемая, общедоступная копия файла, подлежащего проверке, должна быть указана за 72 часа или более до проверки.

4) Нет дизайна на лету. Если есть проблема или проблема, запишите ее местоположение и продолжайте движение.

5) Тестирование, которое проходит все пути в среде разработки, является очень, очень, очень, хорошей идеей. Тестирование, которое требует огромных внешних данных, аппаратных ресурсов, использования сайта клиента и т. Д. И т. Д., - это тестирование, которое стоит целое состояние и не будет тщательным.

6) Не- ASCII формат файла приемлем, если инструменты для создания, отображения, редактирования и т. Д. Существуют или создаются на ранней стадии разработки. Это мой личный уклон, но в мире, где доминирующая ОС не может по-своему обойтись с менее чем 1 гигабайтом оперативной памяти, я не могу понять, почему файлы меньше, скажем, 10 мегабайт должны быть чем-то кроме ASCII или другого коммерческого формата. Существуют стандарты для графики, звука, фильмов, исполняемых файлов и инструментов, которые идут вместе с ними. Нет оправдания для файла, содержащего двоичное представление некоторого числа объектов.

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

Если вы распределены географически, смотреть на экран различий во время разговора с кем-то, кто смотрит на него, было бы относительно легко. Это касается двух человек, которые смотрят на изменения. Для большой группы, которая прочитала рассматриваемый код, несколько сайтов не намного сложнее, чем все в одной комнате. ИМХО, очень хорошо работают несколько комнат, соединенных общими экранами компьютеров и сквош-боксами. Чем больше сайтов, тем больше управления собраниями. Менеджер как фасилитатор может заработать здесь. Не забывайте продолжать опрашивать сайты, на которых вы не находитесь.

В какой-то момент та же организация провела автоматическое модульное тестирование, которое использовалось в качестве регрессионного тестирования. Это было действительно приятно. Конечно, мы тогда поменяли платформы и автоматизированный тест остался позади. Обзор лучше, как отмечает Agile Manifesto , отношения важнее, чем процесс или инструменты . Но как только вы получите обзор, автоматические юнит-тесты / регрессионные тесты станут следующей наиболее важной помощью в создании хорошего программного обеспечения.

Если вы можете основывать тесты на требованиях , ну, как говорит дама в «Когда Гарри встретил Салли» , у меня будет то, что она имеет!

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

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

Я думаю, что во многих отношениях технологии так же важны для культуры и ожидания, как и для конкретного инструмента. Подумайте обо всех импровизациях « Швейцарской семьи Робинсонов » / Флинстоунов / МакГайвера, которые радуют сердце и бросают вызов уму. Мы хотим, чтобы наши вещи работали . Единого пути к этому нет, равно как и «интеллект», который можно каким-то образом абстрагировать и автоматизировать с помощью программ ИИ 1960-х годов .

Большинство пунктов, которые вы описали, являются лишь вопросом форматирования кода или «поверхностного» материала:

• Придерживайтесь соглашений об именах
• Избегайте мертвого кода
• Документ
• ...

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

Я совсем не знаю .NET , но для PHP у нас есть инструменты для проверки такого рода вещей; Учитывая, что .NET часто называют «более индустриальным», чем PHP, я был бы удивлен, узнав, что нет никакого инструмента для проверки такого рода вещей.

Автоматизированный инструмент может одновременно:

• Быть интегрированным в какой-то автоматический процесс сборки , который выполняется каждую ночь
• Отправка отчетов по электронной почте
  • предупреждения (например, метод длиннее 20 строк)
  • ошибки (например, метод длиннее 50 строк)

Письмо может быть отправлено либо всей команде, либо парню, который передал код, который не прошел тест, или вы можете использовать какой-либо веб-интерфейс для отчетов (то же самое о .NET и PHP).

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

Проверки кода, выполненные опытными разработчиками, также имеют еще одно большое преимущество, о котором вы не говорили:

• Опытный developper часто может обнаружить широкий спектр ошибок , просто посмотрев на исходный код (я довольно часто ошибки , когда я делаю проверки кода)
• Проверка кода, выполненная опытным разработчиком, позволит ему высказать замечания и рекомендации команде :
  • Он попытается понять алгоритмы, которые используются в коде, и, возможно, предложить лучшие решения.
  • Просто читая код, часто можно увидеть, что автоматизированный инструмент не обнаружит.

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

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

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

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

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

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

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

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

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

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

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

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

Честно говоря, меня больше всего волнуют «субъективные» вещи, чем все остальное. От хорошего обзора кода я хочу, чтобы кто-то проверял мою логику, а не печатал. И именно на это я обращаю внимание, когда даю обзор кода.

Общий формат, который мне нравится использовать:

1. Что мы исправляем?
2. Что было причиной этого? (посмотрите на код)
3. Как мы это исправляем?
4. Покажите мне новый код
5. Покажи мне работающий код

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

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

Цикломатическая сложность (CC) - это один из способов оценить «неплохой» код.

В реальном коде с высоким CC у меня есть высокий фактор «что здесь происходит, я не помню». Более низкий код CC легче понять.

Очевидно, что обычные предостережения относятся к метрикам.

Обзоры кода являются как субъективными, так и объективными. Правила типа «тело метода должно состоять из 20-30 строк» ​​являются субъективными (некоторые люди могут подумать, что 100 строк - это нормально), но если ваша компания решила, что 20-30 строк - это предел, это нормально, и вы можете измерить это. Я думаю, что система начисления баллов, которую вы придумали, - отличная идея. Вам нужно будет периодически переоценивать его, так как вы обнаружите, что определенные правила должны иметь больший или меньший вес в подсчете очков, но пока все знают правила, это выглядит как хорошая система.

Другие вещи, которые я бы искал:

• ясность кода - иногда фрагмент кода может быть записан в одну или несколько строк. Среднему программисту не нужно тратить несколько минут, пытаясь понять, что делает строка кода. Если он делает, возможно, код должен быть переписан более простым способом. Это субъективно, но ключевым моментом является то, что код должен быть сразу понятен большинству программистов в вашей компании.
• Проверьте входные параметры функции - должен быть какой-то код, чтобы проверить, что входные параметры находятся в допустимых диапазонах. Это также должно соответствовать документации по функциям.
• описательные имена переменных - за исключением нескольких особых случаев (индексы цикла и т. д.), имена переменных должны быть описательными. Одним из ресурсов, на который вы, возможно, захотите взглянуть на соглашения об именах и т. Д., Является Code Complete.

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

Качество кода:

• Автоматизированные проверки:
  • Соответствие стиля: правильное ли соглашение об именах, правильно ли написан код и т. Д.
  • Стандарт эффективности: проверка на утечки памяти, проверка сложности, избыточные переменные и т. Д.
• Актуальная экспертная оценка:
  • Простая прогулка по дизайну
  • объяснение отклонений от автоматизированных проверок
  • Простота обслуживания, поговорим о том, как вы можете поддерживать его и все
  • Тестируемость: насколько легко протестировать этот код? Есть план?

Соответствие функции:

1. Обзор требований к функциям и любые изменения, произошедшие после проверки требований и / или разработки
2. Продемонстрируйте функциональность, связанную с требованиями, и отметьте их один за другим.
3. Обсудите любые дополнительные требования в других аспектах программного обеспечения, встречающихся во время реализации (например, планы развертывания, инфраструктура и т. Д.)
4. Объяснение любых отклонений от требований, если таковые имеются к этому моменту.

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

Я мог бы написать несколько абзацев, но я бы лишь замутил то, что объясняет Карл Вигерс в « Обзорах программного обеспечения: практическое руководство» . Я думаю, что его книга содержит четкие и краткие ответы на ваш вопрос (и многое другое).

По-разному.

Некоторые части обзора легко поддаются количественной оценке (нет проблем с FxCop, нет ошибок StyleCop , нет ошибок CAT.NET и т. Д.)

Стиль, однако, может быть субъективным - но, как вы говорите, как только вы начнете быть более конкретным (без метода> 20 строк), вы сможете измерить его, и такие инструменты, как NDepend, могут сделать это автоматически. Однако некоторые вещи никогда не будут автоматическими - проверка обработки крайнего случая потребует проведения тестов, что приводит к охвату кода, и 100% - недостижимый идеал во многих случаях. Проверка дублирования трудно сделать автоматически. Нулевые проверки, ну, не уверен, что я согласен с вами, но вы можете написать правила NDepend или FxCop для этого.

Чем больше инструментов, тем лучше, и если инструменты позволяют разработчикам проверять свою работу перед внесением изменений и проверками, выполняемыми как часть процесса CI, вы сводите к минимуму необходимость проверок.

Система маркировки звучит сложно, как правильно, но стоит иметь в качестве инструмента измерения: вы не можете улучшить то, что не можете измерить. Но вы, вероятно, должны принять, что некоторые вещи будет трудно / невозможно точно определить количественно. Сложно выяснить, сколько баллов должно получить каждое качество: например, если соблюдение правил именования дает 2 балла, то сколько баллов за сохранение методов маленькими?

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

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

Если вы хотите, чтобы код людей был более стандартизирован, не заставляя их «тратить свое время на форматирование», на что некоторые разработчики будут жаловаться. Инвестируйте в инструмент, такой как ReSharper, так как он делает исправление форматирования и другие задачи по рефакторингу практически автоматизированным процессом.

• Если машина может проверить это, люди не должны.
• Только один элемент контрольного списка: все ли случаи ошибок обрабатываются правильно везде?
• Используйте обзоры кода для улучшения качества и передачи знаний.
• Не используйте обзоры кода для выявления «плохих» разработчиков.
• Эго-звуки более эффективны, чем явные точки.
• Держите это коротким - 90 минут и 500 строк ОГРОМНЫ.