Один из членов моей команды, младший программист, обладает впечатляющими навыками программирования для своего уровня опыта.
И во время проверок кода я верю в то, чтобы подчеркнуть обучение, а не указывать на ошибки.
Но должны ли младшие программисты участвовать в обзорах кода для более старших программистов? Или обзоры кода должны посещать только программисты с соответствующим опытом?
teamwork
code-reviews
pair-programming
Md Mahbubur Rahman
источник
источник
Ответы:
Основная цель проверки кода - найти дефекты или потенциальные проблемы. Обязательными участниками обзора должны быть люди, которые лучше всего подходят для выявления этих проблем, независимо от их звания или стажа работы.
Например, если приложение разрабатывается на Python, и младший инженер имеет больший опыт работы с языком Python, чем старший инженер, который написал код, тогда они могут быть ценным преимуществом в поиске альтернативных методов выполнения чего-либо, но они может также иметь меньше знаний о системе в целом.
Помимо опыта работы с инструментами и технологиями, рассмотрите также опыт работы в области приложений. Кто-то с 20-летним опытом работы, но только 1 или 2 в финансовой индустрии, может помочь, если его общий опыт будет менее опытным разработчиком с 5-летним опытом работы в финансовой индустрии.
Приглашение менее опытных сотрудников для наблюдения и участия в максимально возможной степени процесса проверки кода также может быть полезным, так как позволяет им изучать базу кода, задавать вопросы и узнавать о том, что от них ожидается, не только в обзорах кода, но и в код, который они производят. Однако вы, вероятно, не хотите, чтобы в процесс вовлекалось слишком много людей (вместо этого сосредотачиваясь на людях, которые могут полностью поддержать анализ кода и его цель).
Это действительно относится к любому виду обзора - требования, дизайн, код ...
источник
Да, они должны. Это хороший учебный опыт, чтобы читать код других людей. (И это относится как к хорошему, так и к плохому коду. Хотя можно надеяться, что код старшего разработчика не будет плохим ...)
Очевидно, неразумно, чтобы только юниоры занимались проверкой кода. И неразумно возлагать слишком большие надежды на юниоров с точки зрения того, что они могут найти. Тем не менее, вы также можете быть удивлены свежим пониманием, которое младшие программисты могут предложить.
В другом ответе упоминается, что юноши испытывают чувство страха. Это НЕ то, о чем должно быть рецензирование кода ... ни для рецензируемых, ни для рецензентов. Если это происходит, ваша группа должна изменить способ проверки кода ... и, возможно, нужно обратить внимание на пуговиц.
источник
Я бы добавил, что если «младший» программист не может понять код старшеклассников, то это само по себе является хорошей мерой кода. Хорошо, могут быть случаи, когда просто невозможно написать код, понятный каждому, но, надеюсь, это исключения - если только 1 или 2 человека могут понять код, то что происходит, когда эти люди недоступны, и возникает проблема с Это?
Предоставление людям новых вызовов помогает им развиваться; может также случиться так, что не все исключены для рецензирования кода, но кажется догматичным настаивать на том, что у кого-то есть название ( определяемое кадровой политикой и играми ), прежде чем он сможет помочь в рецензировании.
Как отмечали другие, проверка кода может быть двусторонним процессом; он помогает каждому понять кодовую базу, поэтому делится знаниями, помогает младшим изучать новые и лучшие способы и приемы у своих старших, а также помогает старшим совершенствовать свое понимание и писать, чтобы каждый мог следовать коду, который у вас есть, и который может ловить ошибки.
источник
Целью обзоров кода является выявление проблем, которые не могут быть обнаружены при тестировании, таких как проблемы с обслуживаемостью и угловые случаи. Я бы сказал, что во многих отношениях младшие программисты лучше подходят для этой цели:
Это не значит, что нет других способов, с помощью которых старшие программисты лучше подходят для проведения обзоров, но я хочу сказать, что вы оказываете медвежью услугу, если не в полной мере используете разнообразие своей команды.
источник
Детей часто просят поддержать код, очень важно, чтобы они могли его понять.
Иногда юниоры - единственные люди, которые могут просматривать код старших разработчиков. Стоит ли ждать кода, чтобы перейти к QA (мы не выдвигаем ничего из dev без проверки кода, и я предполагаю, что этот тип проверки кода также), потому что начальник старшего находится в отпуске?
Я также специально просил юниоров анализировать что-то в коде, когда я знал, что в ближайшее время они будут делать что-то похожее для другого клиента, или если бы я знал, что они работали над чем-то похожим или что у них был определенный набор навыков.
Если код довольно прост, я часто заставляю юношу сделать обзор. Зачем тратить время старшего человека, если младший вполне способен выполнять работу? Если юниоры чувствуют себя запуганными, просматривая код старшего, сначала попросите их взглянуть на более простые вещи. В конце концов, вы не можете быть младше, пока не перестанете чувствовать страх.
Я часто обнаруживал, что, если мне придется объяснить код младшему человеку, который его не понимает, я увижу ошибку, которую я сделал (обычно в предположении), и что ни один опытный рецензент не поймал бы, потому что код работает но не делает именно то, что было задумано. Так что сам акт объяснения часто помогает разработчику увидеть проблему, а рецензент не обнаружит ее. Поскольку более опытные люди не часто проходят через код шаг за шагом, такие вещи обнаруживаются легче, когда младший делает обзор.
Я считаю, что участие юниоров в обзорах имеет несколько хороших результатов. Во-первых, это делает их более уверенными, когда они могут понять код старшего человека. Это делает их еще более уверенными, когда они могут найти ошибку в этом коде.
Это подвергает их мыслительным процессам вне их собственных и позволяет им видеть другие способы обработки вещей. Даже как пожилой человек, это случилось со мной - видение другого способа решения проблемы может открыть глаза на новые возможности.
Это помогает им научиться читать код других людей и дает им возможность спросить, что делает код, пока он еще свеж в умах автора. Это намного лучше, чем поддерживать эту идею шесть месяцев спустя, когда автор давно ушел или занят другим проектом и у него нет времени на вопросы.
Это хорошо для старших, потому что оба вопроса раскрывают потенциальные области, где младший слаб и нуждается в наставничестве (чтобы они могли взять на себя большую ответственность и дать старшим больше времени для выполнения других типов задач) или области, где код просто не понятен кто угодно, кроме автора (это означает, что автору может быть неясно даже через год, когда его нужно будет изменить). Это также помогает пожилым людям осознать, что они могут быть умнее, чем они считают. Это помогает держать всех на профессиональном уровне. В конце концов, если вы исключаете юниоров, тогда вы явно подразумеваете, что не думаете, что они способны понять кодекс, который психологически неудачен.
Юниоры, изучающие код пожилых людей, могут вызвать более профессиональное уважение в вашей организации. Старшие могут понять, что они недооценивают юниоров, а юниоры могут понять, что старшие знают больше, чем думали. Юниоры иногда думают, что у них больше навыков, чем у них. Познакомиться с кодом, который они не могут написать, хорошо для этих людей, потому что они начинают понимать, что им нужно многому научиться. Это также подстегнет лучших из них, чтобы получить навыки. В школе иногда студенты B не понимают, почему они не получили A, пока кто-то не покажет им образец уровня A. То же самое с юниорами до старших в обзоре кода.
источник
Мой ответ: иногда . Это будет варьироваться от программиста к программисту и от задачи к задаче.
За:
против:
источник
Я твердо верю, что все члены команды должны участвовать в обеих сторонах проверки кода. Юниоры должны пересмотреть код старшего и наоборот. Почему оба? Потому что обычно дело не только в том, что код «решает проблему». Я не могу сказать вам, сколько раз мне приходилось объяснять кому-то кусок кода и внезапно придумывать гораздо лучший способ сделать это к концу объяснения. Обзоры кода служат, вероятно, 3 целям:
Я младший, и я обычно проверяю старший написанный код. Это общая политика компании «все проверяет код кем-то». Я многому научился благодаря тому, что они пересматривают свой код и имеют возможность задавать вопросы о том, почему что-то делается определенным образом. И иногда я предлагаю более чистый способ сделать определенный кусок кода и тому подобное. Гораздо реже, чем люди, рассказывающие мне, как улучшить мой код, но это произошло хотя бы один раз.
Также важно, насколько формальны ваши обзоры кода. Наши сообщения очень неформальны и состоят из слов «эй, посмотрите на мой код», которые произносят через кабинки или на частном канале IRC. Я мог бы себе представить, если бы вы просматривали код в более формальной обстановке, младший, вероятно, был бы гораздо более обеспокоен рассмотрением кода старшего.
источник
Безусловно, младшие инженеры должны пересматривать код старших инженеров, по крайней мере, иногда.
По моему опыту, довольно редко, когда рецензент в рецензировании кода один на один на самом деле видит ошибку, которую пропускает оригинальный кодер, независимо от того, является ли рецензент старшим или младшим; рецензент даже не должен быть человеком . С другой стороны, очень часто первоначальный кодер распознает ошибку при попытке объяснить код, и чем младше рецензент, тем более вероятно, что это требуется из-за необходимой глубины объяснения.
На мой взгляд, некоторые из часто упускаемых из виду преимуществ обзора кода, которые, возможно, более важны в долгосрочной перспективе, чем обнаружение ошибок:
В обоих этих аспектах младший рецензент имеет тенденцию приносить больше пользы, чем старший.
источник
Младшие программисты должны обязательно выполнять обзоры кода для своих старших коллег!
Однако они не должны быть единственным рецензентом . Соедините их с более опытным разработчиком для каждого обзора кода.
Есть множество преимуществ:
Автор будет вынужден объяснить больше своего кода. Обсуждение вашего кода - один из лучших способов найти проблемы с ним или лучшие способы сделать это.
Автор найдет слабости в их коде. Младший разработчик, скорее всего, будет смущен некоторыми более продвинутыми кусками. Часто они «слишком хитры» для их же блага и могут выиграть от упрощения.
Младший разработчик изучит лучшие практики кодирования. Обзоры кода - это возможность учить на примере.
Младший разработчик будет более эффективным рецензентом кода. Проверка кода сложна . Чем опытнее все с проверками кода, тем быстрее и эффективнее становятся проверки кода.
У младшего разработчика будут более глубокие знания кодовой базы. Будь эгоистом! Вытягивая младших разработчиков рано, вы сможете передать их им раньше.
Младший разработчик будет чувствовать себя более вовлеченным. Младший разработчик начнет видеть «старший» код (и его коллеги) как менее чуждый и пугающий. Это огромное и часто упускаемое из виду преимущество анализа кода.
Младший разработчик - это свежий взгляд. Они не так внушаемы, как те, кто долго работал над кодовой базой. Младший разработчик, скорее всего, укажет разные способы выполнения задач, когда они задают вопросы. Не отмахивайтесь от их диких комментариев, по крайней мере, не задумываясь!
Старшие разработчики несут ответственность. Я часто видел ситуации, когда старшие разработчики, как правило, замаскировали код друг друга (доверие, лень и т. Д.). Дополнительный набор глаз помогает препятствовать этому.
Недостатком является то, что все участвующие стороны потратят немало времени на проверку кода. Таким образом, это может быть немного трудно продать руководству. Тем не менее, преимущества полностью перевешивают медленный темп.
источник
Обзор кода сделан для просмотра кода, а не для обучения. Если бы я был младшим программистом, я был бы напуган, чтобы пересмотреть код старшего.
С другой стороны, чтение кода старшего - отличный способ обучения, при условии, что старший готов ответить на все вопросы.
Две альтернативы могут быть:
источник