Нужны ли обзоры кода для начинающих разработчиков?

39

Я работал в двух компаниях, у каждой из которых была своя методология, когда дело дошло до анализа кода:

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

Однако во второй компании руководителям группы не требовалось проводить какие-либо проверки кода, а просто проверяли функциональность и проблемы с дизайном.

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

user8
источник
28
Если старшие разработчики говорят младшим разработчикам делать что-то определенным образом, часто есть очень веская причина ....
2
@ Tilsan The Fighter: Хорошо, что вы задаете вопросы - пытливым является или должен быть подвиг программиста - но, пожалуйста, сделайте их понятными и легко читаемыми.
Габлин
9
@Thorbjorn - Это верно только в том случае, если старшие разработчики старшие из-за навыков, а не из-за продолжительности. Я видел много плохого кода и дизайна старшими инженерами
KallDrexx
8
Может быть веская причина, и хорошо узнать эту причину, но вы не должны слепо доверять их советам только из-за их звания и X-летнего опыта. Я спросил старшего инженера, почему он написал много плохого кода, и все, что я получил, - это пожав плечами с надписью «Я не знаю». Там достаточно плохих инженеров, чтобы заставить меня понять, что нельзя доверять просто названию.
KallDrexx
4
+1 KallDrexx - это то, что я тоже нашел. У меня часто был «старший» разработчик, который не знал, почему вы не должны просто вставлять все в статический класс, или знать что-либо о тестировании, или знать какие-либо правильные шаблоны проектирования. «Старший» обычно относится к владению недвижимостью, а не к навыкам от что я могу сказать.
Уэйн Молина

Ответы:

107

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

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

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

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

кибер
источник
8
На самом деле, есть смысл не только в том, чтобы руководитель группы делал обзор кода. Даже менее опытный разработчик должен быть в состоянии следовать коду. :)
Guffa
63
Руководители команд должны также пересмотреть свой код, так как часто начинающие разработчики могут изучить ценные методы или, по крайней мере, увидеть, как должен выглядеть «хороший» код. И только то, что вы лидер команды, не означает, что вы не можете ошибиться.
TMN
4
@ TMN, я не могу согласиться больше. Команды не всегда выбираются из-за их навыков или опыта; иногда это все, что осталось после массового исхода (который случался несколько раз, когда я работаю) или большого увольнения. Каждый код должен пройти проверку, независимо от опыта, статуса или названия.
бедуир
2
@ Слишком верно. Название «старший разработчик» не означает «неспособный делать ошибки» или «неспособный к улучшению». Если да, то это не тот старший разработчик, которого я хочу в своей команде.
Брэндон Дюретт
2
Я очень опытен и хорош в том, что я делаю. Я делаю ошибки, многие из которых были обнаружены при проверке кода.
Дэвид Торнли
37

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

РЕДАКТИРОВАТЬ: Причина в том, что рецензент кода сегодня точно так же, как сопровождающий позже. Если код не имеет смысла для него сегодня, он не будет иметь смысла позже, делая ошибки более дорогими для исправления. Следовательно, ДЕЛАЙТЕ это понятным сегодня, пока разработчик все еще помнит код. Также рецензент может увидеть ошибки или упущения, которые пропустил разработчик.

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

оборота user1249
источник
@ Mr.Thorbjorn Равн Андерсен: Не могли бы вы указать, в чем преимущества и недостатки процесса проверки кода?
Санкар Ганеш
2
Вас может заинтересовать это предложение по проверке кода . Было бы неплохо, если бы мы могли поиграть в это.
великий волк
@Victor, интересный подход и желаю удачи.
@Sankar Ganesh: есть бесплатная книга об обзоре кода, в которой обсуждаются преимущества и недостатки: smartbear.com/best-kept-secrets-of-peer-code-review
Джори Себрехтс
17

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

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

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

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

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

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

оборота HLGEM
источник
3
«Мы обнаружили проблемы с компетенцией у новых сотрудников относительно быстро благодаря обзорам кода и, что более важно, по тому, как они отреагировали на проверку кода» - это очень важное преимущество (и я согласен, то, как они отвечают, говорит больше, чем ошибки, которые они делают) ,
Стивен С. Сталь
1
+1 для захвата причины
11

Ловкий парень сказал бы: «Вам не нужно пересматривать код, просто занимайтесь парным программированием и пишите хорошие тесты» :)

Илья К.
источник
9
И часто меняйте пары и признайте, что команда, а не какой-то человек, владеет кодом.
Дон Роби
18
Проворный парень не прав. Код должен быть рассмотрен разумом, который независим от разума (ов), который его создал. (Для пары программистов очень легко говорить друг с другом по тупику, не осознавая этого!)
Питер Боутон,
6
Парное программирование - это непрерывный просмотр кода.
3
@Peter: Agile парень также беспорядочно объединяет пары и практикует общее владение кодом, поэтому в течение определенного периода времени (от нескольких дней до нескольких недель) большинство остальных членов команды проверяли код, написанный первоначальной парой. У ловкого парня есть ответ на все вопросы. Некоторые люди думают , что Agile парень является общим умником.
Том Андерсон
2
Парное программирование устраняет основную проблему с проверками кода - они происходят слишком поздно. Я ненавижу изучать код, чтобы увидеть, что разработчик потратил неделю на перестройку алгоритма библиотеки или структуры данных.
Кевин Клайн
8

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

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

flamingpenguin
источник
2
Да, проверка кода - это такой же контроль качества, как и обмен знаниями. Каждый может извлечь уроки из хорошего обзора кода. Ревизор и рецензент.
Гийом
1
Моя компания похожа на компанию пламенного пингвина. Каждая регистрация проверяется другим разработчиком. Ранг не имеет никакого отношения к тому, кто что рассматривает. Это одноранговый процесс. Требование заключается в том, что весь код проверяется. Обзоры кода в стиле «родитель-потомок» служат только для того, чтобы оттолкнуть разработчиков «А», в результате чего команда «Б» рецензирует юниоров «С». Лучшее, на что может надеяться команда типа «родитель-ребенок», - это посредственный код. Если им повезет.
Джим в Техасе
5

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

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

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

user6061
источник
4

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

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

Брэндон Дюретт
источник
у вас есть официальная статья, обсуждающая в 8-12 раз дешевле? Мы обсуждаем это внутренне.
@ Thorbjørn - Мы делаем: goo.gl/7dMf . Это происходит из нашей книги о проверке кода, которую вы (и любой другой человек) можете получить бесплатно: codereviewbook.com
Brandon DuRette,
2

Я думаю, что пересмотр кода ВСЕ КОДЫ излишним. Количество времени, необходимое для просмотра всего кода, лучше потратить в другом месте. Alterntivley Я думаю, что критический код и / или особенно сложные части требуют пересмотра кода, но, конечно, не каждая строка кода.

Gratzy
источник
7
Я не мог не согласиться больше. Каждая строка кода должна пройти как минимум 2x проверки ... первоначальный разработчик должен проверить абсолютно все изменения строки перед их передачей, и, по крайней мере, еще один разработчик должен выполнить рецензирование в качестве последующей проверки. Очень редко код проходит через обзор без хотя бы одного хорошего вопроса; экспертные оценки также повышают осведомленность членов команды о том, что и как другие выполняют свои задания.
STW
3
@Gratzy - я абсолютно клянусь этим; обычно это добавляет ~ 10 к циклу разработки; небольшая инвестиция за то, сколько мы поймаем на ранней стадии
STW
4
@Gratzy - просто потому, что мы не идеальны. Наша команда значительно выросла, и у нас есть некоторый оборот (в основном подрядчики). В прошлом, когда мы отстали от политики пересмотра, проблемы закрались почти сразу. Процесс проверки - это просто важный шаг в поддержании эффективной команды и производстве качественного продукта. Просмотр всего кода не сложен; особенно если у вас есть пара старших разработчиков, которые очень хорошо умеют находить ненужный код. Большая часть дублирующегося кода происходит от разработчиков, которые преуспевают, но просто не знают о существующем подходе.
STW
5
Я нахожусь с STW в этом - исправление проблем, обнаруженных во время обзора, намного дешевле, чем попытка отладки / сопровождения кода позже, потому что он не считался критическим. Кроме того, проверки кода занимают время только в том случае, если код плохой - хороший код быстро и легко читается!
Питер Боутон
7
Конечно, не должны, но это не значит, что нет! (Сколько команд имеют отличных разработчиков?) Какие строки кода вы не просматриваете? Как вы принимаете решение о том, следует ли пересмотреть конкретное изменение в конкретном файле или нет?
Питер Боутон
2

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

Но как насчет тех компаний, которые не пересматривают код? Вероятно, это компании, у которых много технических проблем и, как говорят потребители, "вылетает" ;-).

Итак, позвольте мне ответить на все ваши вопросы:

  • Да, процесс обзора необходим.
  • Зачем? По причинам, которые я изложил выше.
динамический
источник
2

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

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

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

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

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

Санкар Ганеш
источник
1

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

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

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

JeffO
источник
1

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

Подобный анализ кода бесполезен, но проверка кода с компетентной командой часто может пролить свет на что-то о дизайне (например, почему вы должны делать X и Y, а не Z) или указать фактический недостаток (например, выполнение X приведет к сбою Y по неверным причинам).

Уэйн Молина
источник
1

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

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

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

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

Пол Бучер
источник
-1

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

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

emremp
источник
-1

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

Тим Класон
источник
-1

Они абсолютно необходимы, так как у них мало опыта.

pacoespinoza
источник
без объяснения этот ответ может стать бесполезным в случае, если кто-то постит противоположное мнение. Например, если кто-то публикует утверждение типа «Они абсолютно не нужны, поскольку у них мало опыта», как этот ответ поможет читателю выбрать два противоположных мнения? Подумайте о том, чтобы отредактировать его в лучшую форму
gnat