Каковы общие процессы проверки кода и что считается плохим?

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

Процесс кажется справедливым, однако три человека, которые делают обзоры кода, не кажутся справедливыми. Я замечаю, что когда я помещаю свой код для проверки, я получаю где-то 100-200 комментариев. Верхнее число для меня было 300 комментариев один раз. Конечно, вы могли бы подумать, что это большие изменения, но это также могут быть очень маленькие изменения с менее чем 50 строками кода (включая модульные тесты). Все комментарии считаются «должны делать» и без аргументов.

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

Итак, мой вопрос, если это справедливо? Или обычный?

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

ИМХО, это реальная проблема, поскольку в этом нет приоритетов. Когда вы получаете 100-300 комментариев, некоторые из них должны иметь приоритет A (реальные ошибки), некоторые из них - prio B (которые могут привести к ошибкам позже), а некоторые - prio C (все остальное). Скажите своим коллегам, что вы готовы уважать все их пожелания, но чтобы изменения были эффективными, а ваше время ограничено, настаивайте на расстановке приоритетов. Затем начните с исправления комментария prio A, и если после этого у вас действительно будет время на большее, вы можете начать с B (если вам повезет, ваш босс поймет, что исправление prio B и C не так важно, и даст вам некоторые более важные задачи вместо того, чтобы тратить свое время).

Обзоры кода могут быть спорным процессом.

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

Если это первое, я бы порекомендовал работать над разрешением (новая работа или новые процессы проверки кода).

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

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

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

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

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

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

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

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

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

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

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

² Предполагая, что, хотя комментарии являются чрезмерными, некоторая ценность в них

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

Однако это также зависит от «правил» процесса проверки кода. У ВСЕХ есть свои идеи о том, как что-то должно было быть сделано. Если ваш процесс проверки кода позволяет комментариям иметь форму «Вы должны делать это таким образом, а не таким образом», то вы, вероятно, получите МНОГО комментариев даже для адекватного кода. Если ваш процесс предназначен для поиска «дефектов», то количество комментариев должно быть намного меньше.

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

ОБНОВЛЕНИЕ: С учетом всего вышесказанного, некоторый код просто плохой, даже если без дефектов. В этом случае комментарий должен быть одним комментарием, который говорит что-то вроде. «Этот код необходимо очистить. Пожалуйста, отложите проверку до тех пор, пока код не будет обсужден с [вашим именем здесь]». В этом случае дальнейшее рассмотрение кода должно быть прекращено до исправления комментария.

ОБНОВЛЕНИЕ2: @User: Обсуждаете ли вы свой код / ​​дизайн с одним из них во время его разработки, чтобы вы могли реализовать то, что они ищут, прежде чем вы продолжите делать это по-своему? Вы что-то меняете в том, как вы разрабатываете код, основываясь на их предложениях, или продолжаете думать, что у вас все в порядке? Вы изучаете что-нибудь из их комментариев?

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

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

Некоторые важные различия с процессом проверки нашей команды:

• Основой проверки является контрольный список, составленный всей командой.
• Фокус - дефекты (настоящее и будущее), а не стиль ради стиля.
• 3 инспектора (включая автора) сидят вместе, чтобы просмотреть комментарии. Остались только комментарии с большинством голосов.

Для 50 LOC 300 комментариев кажутся немного чрезмерными и - вау - 3 рецензента на каждый запрос на выборку? Ваша компания должна иметь много ресурсов.

Исходя из моего опыта для полезного процесса проверки кода, должны быть некоторые правила и / или рекомендации:

• Приоритет комментариев
• Классификация комментариев (ошибка, стиль кода и т. Д.)
• Согласованная архитектура / дизайн для подражания
• Согласованный стиль кода

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

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

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

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

Я предлагаю сэкономить время. Ускорьте обратную связь. Я буду:

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

Люди могут возразить против спаривания, потому что «это займет больше времени», но это, очевидно, не проблема здесь.