Какова цель проверки кода

76

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

Итак, какова цель проверки кода?

SoylentGray
источник
16
Связанный (на переполнении стека): цель обзоров кода
yannis
16
- Как бы вы узнали, если вы написали читаемый и легко обслуживаемый код? - Ваш коллега говорит вам после просмотра кода. Обоснование: Вы не можете определить это сами, потому что вы знаете больше как автора, чем сам код. Компьютер не может сказать вам по тем же причинам, по которым он не может определить, является ли картина искусством или нет. Следовательно, вам нужен другой человек - способный поддерживать программное обеспечение - чтобы посмотреть, что вы написали, и высказать свое мнение. Официальное название указанного процесса - «Peer Review» .
комнат
3
"Какова цель обзора кода?" запретить разработчикам писать код Terribad и направлять их в правильном направлении.
zzzzBov
7
Кажется, Code Review может иметь косвенный ответ на этот вопрос ... просто посмотрите на вопросы и ответы там, цель обзора кода становится довольно очевидной :)
Матье Гиндон
3
Интересно, сколько раз программисты обнаруживали ошибки в своем собственном коде просто через простой процесс объяснения своего кода во время обзора?
неактивный топор

Ответы:

75

Есть несколько причин, по которым вы хотели бы провести проверку кода:

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

Существует несколько бизнес-кейсов для проведения обзоров:

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

Если вы ищете всестороннее обсуждение преимуществ и стратегий реализации для экспертных обзоров, я бы порекомендовал проверить экспертные обзоры в Software: A Practical Guide от Karl Wiegers .

Томас Оуэнс
источник
7
+1, я думаю, вы хорошо заметили основные моменты с правильными приоритетами. Поддержание согласованности дизайна при работе с коллегами, которые постоянно находят очень креативные решения "WTF", может быть достигнуто только путем регулярных проверок кода.
Док Браун
Мы делаем обзоры кода в нашем JavaScript-коде, в основном, чтобы убедиться, что разработчики придерживаются указанных стандартов, используют шаблон при разработке модулей, используют предоставленные компоненты и не начинают кодировать ниндзя (намеренно или нет) вокруг проблем, у нас уже есть решения за. Они также прекрасно замечают, что кто-то случайно перезаписывает thisконтекст, а не использует его .hasOwnPropertyв местах, где он должен быть, и т. Д. И т. Д. Итак, главным образом для стандартов. В управляемом языке, таком как C #, у вас, конечно, меньше причин, чем для динамических языков.
Нет,
1
Пока что ваш ответ только намекает на улучшения в правильности кода. Он не учитывает удобочитаемость / удобство сопровождения кода, который редко может быть точно определен количественно разработчиком.
Артс
51

Обзоры кода являются инструментом для передачи знаний .

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

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

    Тщательный анализ кода потребует частых проверок различной документации. Это отличный способ выучить язык или API.

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

Обзоры кода не о:

  • ... поиск ошибок. Для этого и нужны тесты. По-прежнему часто случается, что проверка кода находит какую-то проблему.

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

Амон
источник
2
Ваш последний пункт о придирчивых вопросах стиля, с которым я не совсем согласен - у нас только что был мучительный опыт рассмотрения кода младшего разработчика, и самая яркая жалоба была на самом деле о стиле, но не о тех проблемах стиля, которые легко программируются принудительно .... waaaaaay слишком много, если заявления для пограничных случаев и т. д .; проблемы, которые да, вы могли найти компьютер в некоторых случаях, но большинство из них не были общими для поиска по сценарию. Нам нужно 30 секунд чтения, чтобы начать его видеть, еще 30 секунд, чтобы объяснить разработчику и, надеюсь, исправить проблему. Все еще в шоке от этого: /
пацифист
7
@pacifist Это не тот стиль, который описывает ответчик. Стиль - это расположение скобок, отступов и так далее. Если ваш младший разработчик использует слишком много операторов if, у вас совершенно другая проблема, чем у стиля; Общий атрибут кодирования STYLE заключается в том, что он не влияет на производительность. И я думаю, что значительное количество if-утверждений повлияет на производительность.
Пимгд
12
Когда я делаю обзор, я часто замечаю вещи, которые, по моему мнению, «это похоже на ошибку», затем я пишу специальный тестовый пример, чтобы доказать, что это ошибка. Так что одна из многих целей анализа кода - поиск ошибок. Вот почему я думаю, что точка зрения «либо проверка кода, либо тестирование» слишком односторонняя.
Док Браун
2
В дополнение к @DocBrown есть случаи, которые не могут быть легко проверяемыми - гонки данных, некоторые типы взаимоблокировок, блокировки блокировки, неопределенные поведения / значения (в основном в C / C ++, но также порядок элементов в хеш-таблицах в undefined) или поиск ресурсов. (Открытие файла в цикле может быть плохой идеей даже с GC). Некоторые из этих вещей могут быть обнаружены с помощью достаточно интеллектуального статического анализа .
Мацей Пехотка
2
@pacifist ваш конкретный пример будет полностью взорван в обзоре кода. Это также будет красным флагом для любого статического анализатора кода (Cyclomatic сложно 17!). Обзор кода быстро идентифицирует эту функцию как проблему в семантическом стиле (или даже в алгоритме!). Тем не мение. Этот вид проблемы не просто проблема стиля. Если вы будете относиться к нему как к такому, то в скором времени в вашем репозитории появится действительно неприятный код; В конце концов, это просто «стиль».
Пимгд
12

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


источник
2
Похоже, это не дает ничего существенного по сравнению с предыдущими 4 ответами
gnat
2
@gnat: другие ответы касаются передачи знаний и выявления ошибок. Это важно, но есть еще кое-что для обзора кода.
1
Насколько я могу судить, в этом ответе обоснованно рассмотрено многое другое : «Если вы ищете исчерпывающую дискуссию о преимуществах и стратегиях реализации для экспертных проверок, я бы порекомендовал проверить экспертные обзоры в программном обеспечении: Практическое руководство Карла Вигерса ". Этот ответ также охватывает это: «корректирующее действие против чрезмерно сложного кода»
комнат
2
@gnat Это подчеркивает другой аспект вопросов, поднятых в других ответах. Вы когда-нибудь были озадачены вашим собственным кодом, который вы написали шесть месяцев назад? Проверка кода позволяет ускорить этот процесс. Если ваш коллега озадачен вашим кодом, вы все равно можете уточнить его, пока проблема еще свежа в вашей памяти.
200_success
1
@ 200_success возможно. Но этот момент, если он действительно там, выглядит очень плохо представлен. Даже ваш комментарий удастся донести до него лучше, чем этот «ответ». Не говоря уже о том, что он просто повторяет то, что было указано в предыдущем комментарии, который ссылается на канонический ответ, объясняющий это в связанном вопросе
комнат
7

Я хотел бы добавить две области, не охваченные другими хорошими ответами:

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

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

Крис Найт
источник