Нужны ли обзоры кода младшим разработчикам?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я работал в двух компаниях, каждая из которых использовала разную методологию проверки кода:
В первой компании проверка кода проводилась руководителями групп и требовалась после завершения каждого модуля.
Однако во второй компании от руководителей групп не требовалось проводить какие-либо проверки кода, а просто проверяли наличие проблем с функциональностью и дизайном.
Так что я в замешательстве.Действительно ли необходим процесс проверки кода?Если да, то почему?А если нет, то почему бы и нет?
Решение 10
Обзор кода: Процесс проверки кода должен быть жизненно важный Один для всех, я объясню, кто все получит преимущества из -за проведения проверки кода, а также того, какие преимущества они получают.
1. Преимущества, полученные Компанией из -за проведения проверки кода:Если проведен частый обзор кода, то компания может получить конечные продукты гораздо более оптимизированным образом, что поможет им получить фирменное название на своем рынке, а также помочь компании получить или улучшить их текущий Cmmi уровень.
2. Преимущества руководителю команды из -за проводимости обзора кода:Как мы все знаем, учитель может легко идентифицировать ошибки, потому что они чаще рассматривают ответы своих учеников, поэтому они могут получить идею, в которой могут быть возможности для неправильных вещей. Точно так же руководитель команды также знает, что в этих областях идет не так. Как мы можем исправить их. И также помочь руководителю команды получить идеи новостей от младшего разработчика.
3. Преимущества для младшего разработчика из -за проводимости обзора кода:Младший разработчик может легко получить идеи о процессе обзора кода, а также они могут получить то, что является стандартом кодирования, например: для правильного создания API, они узнают стандартизацию кодирования, которая может помочь им в будущем специально Когда они станут в пост более высокого уровня.
Таким образом, мой вывод - обзор кода - очень важный процесс для всех [даже для членов команды], поскольку обзор кода помогает нам исправить наши небрежные ошибки в нашем коде, потому что мы все люди, поэтому мы не можем предсказать, что мы никогда не Сделайте небрежные ошибки в коде.
Другие советы
Я лично считаю, что каждый кусок кода должен пройти через обзор кода, не имеет значения, являетесь ли вы младшим или старшим разработчиком.
Почему? Для начала в вашем названии ничего не говорится о том, как вы развиваете, и старший разработчик может чему -то научиться у юниора. В нашей компании мы переключаемся вокруг, поэтому один из других членов команды рассмотрит ваш код ... в основном мы объединились «младший» и старший вместе, так что все, что не говорят ежедневно, может быть попал в продолжение. Если старшему не нравится младший код, он должен послушать, почему младший сделал, как он это сделал, и посмотреть на него, и посмотрите, является ли это возможным решением, которое может быть использовано в будущем ... это вопрос того, чтобы стать мудрее, независимо от кто ты.
Одна важная вещь об обзоре кода - не слишком хороша, если вы хороший парень, вы просто позволите, чтобы развиваться все больше и больше грязного кода в системе. Как и вчера, я начал переработать полное заявление, которое писал бывший нанятый Juniordeveloper, и мой Бог, что Кодекс мог понадобиться, прежде чем он ушел.
Я не понимаю, почему это должен быть лидер команды, выполняющий обзоры, но требует человека, который не боится выбрать «бой» за кусок плохо разработанного кода, и это должен быть человек, который заботится о том, как должен быть. Не все компании нанимают людей, которые на самом деле заботятся о том, что они делают, и эти плохие яйца не должны быть разрешены провести отзывы о коде, поскольку они, вероятно, просто пожимают плечами и говорят «ОК» плохим коду.
По сути, проверка кода необходима всем программистам, независимо от опыта.Это контроль качества разработки программного обеспечения и одна из причин, по которой открытый исходный код может быть очень высокого качества.
РЕДАКТИРОВАТЬ:Причина в том, что рецензент кода сегодня выполняет точно такую же роль, как и сопровождающий позднее.Если код не имеет смысла для него сегодня, он не будет иметь смысла и позже, что сделает исправление ошибок более дорогим.Следовательно, СДЕЛАЙТЕ это понятным сегодня, пока разработчик еще помнит код.Также рецензент может увидеть ошибки или упущения, которые упустил разработчик.
К сожалению, очень немногие хотят это делать, но с точки зрения бизнеса это должно быть обязательным.
Я работаю в месте, где обзор кода теперь является требованием, но не было всего 3 года назад. Он сделал огромное улучшение в нашем коде и способности других поддерживать код позже. Даже старшие, очень опытные разработчики делают ошибки, которые легко и тихо исправить в обзоре кода, прежде чем QA найдет их или в худшем случае, прежде чем клиент найдет их. Далее, по крайней мере, один человек, отличный от организатора разработчика, знаком с кодом.
Часто, когда организация пробует что -то новое для этого, как мы делали с обзором кода, существует большое сопротивление изменениям. Я почти ничего не видел (мы были устойчивы, чтобы получить официальный отдел качества.) С обзором кода. В значительной степени требуется только один или два обзора, чтобы увидеть ценность.
Я нашел новые методы, которые я не рассматривал как при рассмотрении кода чужой работы, так и в рассмотрении моего кода. Мы нашли проблемы с компетенцией с новыми сотрудниками относительно быстро, имея обзоры кода и, что более важно, благодаря тому, как они реагировали на обзор кода. Мы узнали, что сейчас кажутся совершенно ясными в гуще программирования, который не будет ясным при техническом обслуживании. Это бесценно. Может быть, единственное, что нужно, - это комментарий относительно того, почему что -то было сделано. Мы обнаружили некоторые фундаментальные недоразумения по поводу нашего дизайна базы данных, которые необходимо исправить, чтобы отчет действительно имел правильную информацию.
Часто то, что я видел в обзоре кода, так это то, что, благодаря тому, чтобы объяснить что -то другому, у разработчика будет включен лампочка в его голове и понимает, что есть ошибка, которую рецензент не видел.
И мальчик может кодировать обзор, идентифицируйте тех программистов -ковбоев, которые не будут следовать каким -либо стандарту или использовать обязательные инструменты и код которого будет почти не поддается всем остальным. И это может заставить их получить с помощью программы или уйти.
Люди, наиболее устойчивые к обзору кода, часто являются людьми, от которых организациям больше всего нужно избавиться, потому что они знают в своих сердцах, их код не может пройти проверку кода.
Agile Guy сказал бы: «Вам не нужен обзор кода, просто делайте пару программирования и напишите хорошие тесты» :)
Обзор кода - хороший способ распространения Knowlege и хорошей практики через команду. По моему опыту, это хорошая идея, чтобы убедиться, что весь код будет рассмотрен, и попытаться изменить, кто рассматривает какой код.
В моей нынешней команде код каждого из них пересматривается одинаково, и программист и рецензент должны быть удовлетворены кодом, прежде чем он будет выпущен. Это относится как к старшим разработчикам, рассматриваемым большим количеством младших разработчиков, младшего разработчика, рассматривающего другого или других старших разработчиков, рассматривающих друг друга. Если рецензент неопытен или не чувствует себя комфортно, просматривая какой -либо конкретный код, то он объединится с другим разработчиком (и, возможно, также с оригинальным разработчиком), чтобы сделать обзор как группу.
Я работал в бизнесе более 20 лет, работаю в компании -разработчиках программного обеспечения и для разных предприятий, и ни в одном из этих мест не было процесса проверки кода. Тем не менее, я могу понять и оценить преимущества его наличия. По сути, насколько я понимаю, они должны использоваться для обеспечения соблюдения стандартов, за которыми следует следовать, чтобы другие могли бы более легко поддерживать код в будущем. Почитаемость кода также может быть проверена в процессе рассмотрения, так как это также гарантирует, что обслуживание может эффективно работать с кодом.
В настоящее время я работаю в небольшом магазине, где я единственный разработчик. Иногда мы приносили подрядчиков, чтобы помочь с отставанием. По крайней мере, один или два из этих подрядчиков написали код, который не обязательно соответствовал моим стандартам или стандартам компаний, но он работал хорошо и, по крайней мере, несколько понятно. Когда я указал на этот вопрос руководству, им было все равно, они просто хотели знать, сделало ли он то, что мы им заплатили. Итак, я полагаю, это только зависит от компании, и чист, простым в поддержании кода является желаемый продукт, или если они просто хотят чего -то, что хорошо работает за деньги.
Очевидно, как разработчик, и тот, кто должен поддерживать код, я хотел бы работать с чистым кодом, который следует за каким -то стандартом, но у меня не всегда есть такая роскошь, поэтому я делаю все возможное и имею дело с тем, что у меня есть , даже если это означает, что иногда приходится переписывать какой-то код в моем собственном стандарте.
Обзоры кода могут определить дефекты ранее в жизненном цикле программного обеспечения, когда проблемы проще (и дешевле) исправить. В Умный Мы разработали Инструмент проверки кода сверстника и также провели много исследований о том, как сделать обзоры кода эффективными. Основываясь на данных от наших клиентов, дефекты, обнаруженные в проверке кода, 8-12x дешевле найти и исправить, чем дефекты, обнаруженные в QA. Одна только экономия затрат стоит того, что стоит того, но это больше ценности, чем просто. Обзор кода - отличный способ для всех в команде учиться и улучшаться в качестве разработчиков программного обеспечения.
Есть некоторые ловушки, которые могут привести к тому, что обзоры кода станут менее эффективными, и кажется, что ваша организация попадает в одну из них. Сделайте обзор кода о коде, а не о людях. Названия ничего не значат в обзоре кода. Апелляция на власть (вы должны сделать это по -своему, потому что я руководитель команды) приносит больше вреда, чем пользы. Учить вместо этого. Старшие инженеры должны объяснить, почему это должно быть сделано на своем пути, а не только требовать, чтобы это было. Если вам трудно объяснить концепцию, это тоже для вас опыт обучения. Вы оба будете лучшими разработчиками для усилий, которые вы приложили.
Я думаю, что проверка кода весь код является излишним. Количество времени, необходимое для просмотра всего кода, может быть лучше потрачено в другом месте. Aldertivley Я думаю, что критический код или или особенно сложные произведения нуждаются в обзоре кода, но, конечно, не каждой строке кода.
На мой взгляд, код, который будет использоваться компанией, независимо от того, был ли он написан младшим или старшим застройщиком, всегда должен быть рассмотрен. Почему? Потому что, если у кода было несколько ошибок? А что, если в течение времени использования этого кода программа разбилась? Чтобы остановить эти вещи, весь код должен быть рассмотрен перед использованием.
Но как насчет тех компаний, которые не рассматривают код? Это, вероятно, компании, у которых много технических проблем и много, как говорят потребителей, «сбои» ;-).
Так что позвольте мне ответить на все ваши вопросы:
- Да, процесс обзора необходим.
- Почему? Из -за причин, по которым я заявил выше.
Какая разница между вмешательством в ваши идеи до проверки вашего кода (ревью) или после него из-за ошибки, слишком умного/сложного для понимания или несоблюдения принятых стандартных практик?Это ваше эго?
Вы не можете пренебрегать достоинствами проверки кода или чего-либо еще только потому, что она плохо реализуется менее квалифицированным членом команды, которого вы не уважаете.Code Review — это не какой-то очень сложный процесс, который способны освоить лишь несколько суперпрограммистов.Я не уверен, что найдется много программистов или профессиональных писателей, которые способны или имеют время для самостоятельного редактирования.
Вы когда-нибудь возвращались к строке кода несколько месяцев спустя и задавались вопросом, о чем я думал?Было бы больше шансов обнаружить это при проверке кода.Вы только что уловили это, и вы лишь немного лучше, чем программист, которым вы были некоторое время назад - я надеюсь.
IMO Обзор кода должен быть важен для всех разработчиков, но Только когда люди, делающие обзор, сами по себе компетентны. В прошлом у меня был отклонен код в обзоре, потому что я не шучу, я следил за SOLID, сделал некоторый впрыск зависимостей и провел код, организованный в пространства имен и папки в соответствии с логическим дизайном, и включал небольшой набор модульных тестов для проверки кода. Код был отвергнут как «слишком сложный», и мне сказали использовать один класс, который все вместе сморщил и удалил тесты, потому что это не то, как компания написала код.
Подобный обзор кода бесполезен, но обзор кода с компетентной командой часто может осветить что -то о дизайне (например, почему вы должны делать x и y, но не z) или указать фактический недостаток (например, выполнение x вызовет y по неправильным причинам).
Конечно, обзор кода не нужный. Анкет Опять же, ни один из тестов, непрерывная интеграция, управление источником, участие клиентов, профилирование, статический анализ, приличное оборудование, сборки одного щелчка, отслеживание ошибок, список можно продолжить.
Наряду с обзорами кода, я упоминал выше, это инструменты, которые помогают обеспечить качество программного обеспечения. С сочетанием навыков, удачи, времени и решимости; ты Можно доставить качественное программное обеспечение без чего -либо из этого, но более вероятно, что вы не будет.
В вашем сценарии не о чем можно смутить. Не каждая организация потворствует любой лучшей практике. Они могут не согласиться с этим, это может противоречить другой лучшей практике, которую они реализуют, или они могут считать, что накладные расходы в его реализации слишком велики для них на данный момент. В зависимости от их обстоятельств, они могут быть правы при этом, или они могут создавать ложную экономику. Для некоторых инструментов (например, управление источником) коэффициент окупаемости/усилий настолько хорош, что использование его не является сложно; Для других это менее ясно.
Нет сомнений в том, что обзор кода - это практика, которая вводит значительные накладные расходы. Из -за этого организации будут стремиться свести к минимуму эти накладные расходы, либо не делая этого вообще, либо делая это только в определенных ситуациях (например, для младшего члена команды, либо особенно волосатые изменения). Не всегда очевидно, что он окупается больше (при уловке ошибок, сокращении технических долгов или совместном использовании знаний), чем затраты. Большая часть этой окупаемости трудно определить количественно, тогда как очень легко подсчитать количество человеко-часов, которые ваша организация тратит на обзоры. Самый простой бит для количественной оценки (уменьшенное количество ошибок) легко приписать другим факторам (например, «Конечно, у него меньше ошибок, это более зрелое»).
Мы делаем онлайн -футбольный матч в Турции. Многие пользователи и магистры игры помогают нам по функциональности. Также они дают комментарии по необходимым функциям. Поэтому я думаю, что если у вас много пользователей, могут быть сделаны функциональные тесты для помощи или получения значков. Колобирование разработчиков, магистров игры и пользователей с форумами, командами поддержки и частными тестовыми средами создает социальное проект.
Необходимы обзоры кода и обмена между командой разработчиков, но если это не важно, вам не нужно заставлять себя.
Я думаю, что то, насколько словеса 2 -я проверка, зависит от вашего жизненного цикла, будь то гибкий или более водопад в своих процессах. Я думаю, что разумно выполнять проекты/инспекции высокого уровня, а также более подробные проверки дизайна уровня. Я думаю, что также хорошо привлечь нескольких членов команды, чтобы осмотреть.
Они абсолютно необходимы, поскольку у них мало опыта.
