Должны ли младшие программисты участвовать в качестве рецензентов кода в проектах старших программистов?

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

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

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

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

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

Помимо опыта работы с инструментами и технологиями, рассмотрите также опыт работы в области приложений. Кто-то с 20-летним опытом работы, но только 1 или 2 в финансовой индустрии, может помочь, если его общий опыт будет менее опытным разработчиком с 5-летним опытом работы в финансовой индустрии.

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

Это действительно относится к любому виду обзора - требования, дизайн, код ...

Должны ли младшие программисты участвовать в качестве рецензентов кода в проектах старших программистов?

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

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

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

Я бы добавил, что если «младший» программист не может понять код старшеклассников, то это само по себе является хорошей мерой кода. Хорошо, могут быть случаи, когда просто невозможно написать код, понятный каждому, но, надеюсь, это исключения - если только 1 или 2 человека могут понять код, то что происходит, когда эти люди недоступны, и возникает проблема с Это?

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

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

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

• У них больше свободного времени в целом.
• Они с большей вероятностью будут делать это медленно, построчно, из-за необходимости понимать код.
• Когда вы говорите о том, что код можно поддерживать, это означает каждый в компании, а не только ваши лучшие программисты. Это означает, что ваши младшие программисты должны уметь понимать код, чтобы объявить его поддерживаемым.
• Они часто менее склонны делать неверные предположения, полагая, что что-то работает так, как они предполагают, что оно должно работать.
• Их обучение на языке программирования является более поздним, и с меньшей вероятностью будет запутано вместе с многолетним опытом работы на другом языке. Например, старший может случайно использовать привычку, которую он подхватил в C ++, которая компилируется, но работает немного по-другому в Java. Юниоры легче воспринимают подобные ошибки.
• Рецензентам кода нужно только выявлять проблемы, а не обязательно предлагать лучшее решение. Они часто комментируют: «Я не могу понять, как это сделать лучше, но эта часть действительно сбивает с толку из-за всех повторений». Более опытный программист может легко внести улучшения, даже если они сначала не заметили проблему.

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

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

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

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

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

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

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

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

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

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

Юниоры, изучающие код пожилых людей, могут вызвать более профессиональное уважение в вашей организации. Старшие могут понять, что они недооценивают юниоров, а юниоры могут понять, что старшие знают больше, чем думали. Юниоры иногда думают, что у них больше навыков, чем у них. Познакомиться с кодом, который они не могут написать, хорошо для этих людей, потому что они начинают понимать, что им нужно многому научиться. Это также подстегнет лучших из них, чтобы получить навыки. В школе иногда студенты B не понимают, почему они не получили A, пока кто-то не покажет им образец уровня A. То же самое с юниорами до старших в обзоре кода.

Мой ответ: иногда . Это будет варьироваться от программиста к программисту и от задачи к задаче.

За:

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

против:

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

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

1. Убедитесь, что код правильный
2. Заставьте писателя задуматься о том, как другие увидят свой код
3. Получите отзывы читателей о том, что можно улучшить, и в целом о второй паре глаз

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

Также важно, насколько формальны ваши обзоры кода. Наши сообщения очень неформальны и состоят из слов «эй, посмотрите на мой код», которые произносят через кабинки или на частном канале IRC. Я мог бы себе представить, если бы вы просматривали код в более формальной обстановке, младший, вероятно, был бы гораздо более обеспокоен рассмотрением кода старшего.

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

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

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

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

В обоих этих аспектах младший рецензент имеет тенденцию приносить больше пользы, чем старший.

Младшие программисты должны обязательно выполнять обзоры кода для своих старших коллег!

Однако они не должны быть единственным рецензентом . Соедините их с более опытным разработчиком для каждого обзора кода.

Есть множество преимуществ:

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

• Автор найдет слабости в их коде. Младший разработчик, скорее всего, будет смущен некоторыми более продвинутыми кусками. Часто они «слишком хитры» для их же блага и могут выиграть от упрощения.

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

• Младший разработчик будет более эффективным рецензентом кода. Проверка кода сложна . Чем опытнее все с проверками кода, тем быстрее и эффективнее становятся проверки кода.

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

• Младший разработчик будет чувствовать себя более вовлеченным. Младший разработчик начнет видеть «старший» код (и его коллеги) как менее чуждый и пугающий. Это огромное и часто упускаемое из виду преимущество анализа кода.

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

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

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

Обзор кода сделан для просмотра кода, а не для обучения. Если бы я был младшим программистом, я был бы напуган, чтобы пересмотреть код старшего.

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

Две альтернативы могут быть:

• пусть юниоры посещают собрания по пересмотру кода и пусть каждый сопровождающий будет открыт для некоторых обсуждений преподавания / обучения
• попрактикуйтесь в парном программировании