Из руководства POV: Сколько стоит обзор кода?

Ответ 1

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

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

Возможными юридическими проблемами могут быть: unattributed/unlicensed code, смешивание gpl-кода с кодом non-gpl (при условии, что конечный продукт не сделает доступным источник).

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

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

• Успешно проверены коды. Многие ошибки найдены и исправлены.
• Клиенту нравятся изменения.

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

Ответ 2

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

Ответ 3

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

И без высокого качества вы потеряете время (и, следовательно, деньги) в долгосрочной перспективе.

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

(EDIT: для некоторых данных о рентабельности обзора кода я бы предложил проверить образец главы Случай для экспертного обзора из книги Best Kept Secrets of Peer Code Review от SmartBear, особенно на странице 9. Как менеджер, управляющий ресурсами (вздох), вам может показаться интересным, и это может изменить вашу точку зрения на то, что действительно отвлекает.)

Ответ 4

Существует множество доказательств для поддержки отзывов по коду:

• Классический Fagan исследование
• Пример исследования, в котором компания могла бы сэкономить 200 тысяч долларов, если бы делали отзывы
• В этой книге есть больше исследований. Википедия статья
• И в Software Inspection содержится еще несколько тематических исследований.

Есть еще много тематических исследований, которые вы можете найти в Интернете.

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

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

Ответ 5

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

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

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

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

Посмотрите на это по-другому - вы говорите, что ваши коллеги в настоящее время лучше пишут, более чистый код, когда вы смотрите через их плечо, но не тогда, когда вы этого не делаете. Пересматривая свой код после факта и давая им хорошую обратную связь, это похоже на то, как смотреть через плечо, когда вы даже не находитесь в здании. И то же самое от вас к вам - я думаю, что 90% ясности моего собственного кода (например, это) происходит от меня, глядя на то, что я написал и думал: "Когда люди читают это, что они будут думать?". Я видел код, который я написал, когда был программистом-одиночкой, и он был непроницаем. Теперь, даже когда это персональный проект, а "люди" - это только я, есть определенный настрой, из которого вы получаете представление о том, что у вас есть читатели.

Тот, кто когда-либо работал с моим кодом, теперь ваш шанс сказать, что он все еще непроницаем; -)

Ответ 6

Это зависит от того, как выполняются проверки кода, насколько они того стоят и что еще находится в системе.

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

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

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

Ответ 7

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

Некоторые менеджеры просто недальновидны и нуждаются в знаниях о преимуществах обзоров кода.

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

Это ссылка на интересное интервью следующего stackoverflower Alex Martelli о обзоре кода.

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

Ответ 11

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

Ответ 12

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

Ответ 13

Качество кода - это еще одна вещь, которую нужно учитывать вместе с другими ответами на эту должность.

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

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

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

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

Ответ 14

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

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

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

Ответ 15

"Неоценимый" - это короткий ответ, который вы ищете.

Вы не "зря" (как вы выразились в одном комментарии) один разработчик, попросив его или ее посмотреть другой код разработчика. Имея строгий режим проверки кода, вы повышаете качество своего кода и, как следствие, качество и надежность вашего продукта. Затраты, которые вы понесете вперед, потратив время на просмотр кода, будут более чем компенсированы сохраненными по времени ошибками исправления.

Там аксиома, в которой говорится, что ошибка стоит в 10 раз больше, чтобы исправить все стадии развития, которые она преодолела. То есть, ошибка, которая делает ее к QA, стоит в 10 раз больше, чем исправление, которое было обнаружено в первую очередь разработкой. Ошибка, которая заставляет его пройти QA, стоит в 10 раз больше, чем исправление, которое было обнаружено QA, и в 100 раз больше, чем исправление, которое было обнаружено на ранней стадии разработки в обзоре кода, автоматизированном unit test или другом, Я думаю, что в этой конкретной теории существует много правды.

Кроме того, вы предполагаете, что

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

Это не такая большая проблема, если вы регулярно проводите обзоры дизайна и кода. Сам акт участия в этих обзорах делает по определению "знакомым с кодом" и решает проблему, что рецензент не принимал участие в большинстве проектных решений (потому что они есть).

Ответ 16

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

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