Как оставить отзыв после проверки кода

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

1. Должен ли я исправить код сам?

2. Должен ли я дать им отзыв о процессе проверки и позволить им исправить в соответствии с моими инструкциями? И если да, то как мне дать этот отзыв, заполнить ли я определенный шаблон документа и отправить его им, или есть какое-то программное обеспечение, которое поможет мне пометить вещи с проблемами в файлах кода, где они могут позже проверить это? (Я использую Visual Studio).

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

Краткий ответ

Должен ли я исправить код сам?

Нет.

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

Да. Согласно вашим предложениям , а не инструкциям . Инструкции звучат слишком авторитетно.

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

Используйте инструмент, чтобы дать обратную связь. Вы можете использовать Visual Studio.

Длинный ответ

Раньше я использовал Visual Studio, но мне постоянно приходилось спрашивать других разработчиков: «Эй, можешь отправить мне свою работу, чтобы я мог ее просмотреть?» Мне это не понравилось, и это никогда не получалось очень хорошо. Теперь я использую помощник по рассмотрению, потому что я могу начать проверку с проверки. Мне не нужно полагаться на другого разработчика, отправляющего мне работу на проверку. Это также помогает мне пометить элементы как дефекты или просто пометить элементы, которые должны быть просмотрены автором. Это работает для нашей команды, потому что, как только мы начинаем рецензирование, оно остается прямо на доске рецензий и не теряется в переводе. Это интегрировано с Visual Studio. Как я уже упоминал, Visual Studio также имеет собственный процесс рецензирования, но я считаю, что он имеет ограничения, и этот процесс не является естественным; поэтому я использую Review Assistant.

Этот инструмент также помогает в процессе туда и обратно, обсуждения и т. Д.

Процесс, более или менее, выглядит следующим образом:

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

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

Плохой выбор формулировки

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

Я вместо этого говорю это:

Лучший выбор формулировки

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

Это заставляет автора думать:

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

Этот простой выбор слов очень помог мне.

Я никогда не недооцениваю младших разработчиков. Я работал с некоторыми старшими разработчиками (более 10 лет опыта), и там код был хуже, чем младший студент кооператива. Так что просто потому, что они старшие или младшие, не так уж важно; их работа - это то, что говорит громче, чем годы опыта.

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

Можете ли вы рассмотреть какой-то код для меня, потому что я не могу понять это.

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

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

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

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

Я никогда не исправляю код самостоятельно, потому что:

1. Автор не будет учиться на этом.
2. Это как я говорю: «Отойди в сторону, позволь мне показать тебе, как это делается. Мой код лучше твоего».
3. Почему я должен? Это больше работы для меня.

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

Если вы продолжаете делать обзоры, вы рано или поздно получите действительно хорошее представление об уровне знаний каждого разработчика в команде. Знание этого действительно полезно, и вам нужно воспользоваться этим и раскрыть его. Вот как: если я проверяю некоторый код и вижу очевидные области для улучшения, и я знаю, что другой разработчик тоже может их поймать, я заставлю их просмотреть его. Что-то вроде «Эй, я вижу несколько областей, которые можно улучшить. Можете ли вы рассмотреть это более подробно и отправить свои комментарии автору?» Это тоже прекрасно работает, потому что теперь у меня есть 2 других разработчика, работающих друг с другом.

Если я рассматриваю какую-то работу и замечаю что-то, от чего может выиграть вся команда, то я создам гипотетический сценарий и объясню проблему на собрании. Я начну с объяснения сценария и спрошу всех, могут ли они найти проблему или увидеть проблему, вовлечь их. Заставьте всех задавать вопросы. Тогда, наконец, представьте лучший подход. Если у кого-то есть лучший подход, я благодарю его и признаю перед командой, что этот подход лучше. Это показывает, что я не являюсь человеком типа «мой путь или шоссе». Кроме того, я НИКОГДА не открываю чью-то работу и начинаю указывать на проблемы на собрании, автор не оценит ее - независимо от того, насколько я хорош и безвреден.

Когда я делаю обзоры, я не просто ищу хороший чистый код, но и то, что делает код. Если бизнес-требование: Если сотрудник работает в компании более 10 лет, увеличьте его на 5%. В противном случае 2,5% . Первое, что я проверяю, это то, что он на самом деле делает это. Затем я проверяю, делает ли он это чистым, последовательным и производительным способом.

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

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

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

Ответьте на некоторые из ваших пронумерованных вопросов

1- я должен сам исправить код?

Нет, пожалуйста, посмотрите причины, которые я изложил выше.

2- Должен ли я дать им отзыв о процессе проверки и позволить им исправить в соответствии с моими инструкциями?

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

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

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

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

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

Последние мысли

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

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

Я написал пост в блоге под названием « Обзоры кода стоит вашего времени»? подвести итог процесса, используемого моей командой. Выводы, поскольку они относятся к вашему вопросу, будут:

1. Пусть разработчики исправят код. Это позволит им лучше понять ваши комментарии (или понять, что они не до конца понимают их и спросить), а выполнение задания - лучший способ изучения, чем только чтение об этом.
2. Программное обеспечение для обзоров кода это путь. Доступно много вариантов, как с открытым исходным кодом, так и проприетарных. Большая часть этого работает с Git. Моя команда использует BitBucket (ранее известный как Stash), есть также GitLab и GitHub, Gerrit (я лично не являюсь его фанатом) и множество других. Большинство этих приложений основаны на веб-технологиях, поэтому не имеет значения, какую IDE вы используете, но есть также плагины для многих IDE, так что я уверен, что есть и для Visual Studio. Подобное программное обеспечение позволяет просматривать код до его слияния с основной ветвью (обычно с помощью запросов извлечения) и отображать измененные части и некоторые контекстные строки вокруг каждого изменения. Это делает обзор кода свободно и без проблем.

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

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

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

Кроме того: не будьте единственным, кто просматривает код.
Позвольте некоторым опытным членам вашей команды также взглянуть на код и запланировать регулярное совещание по рецензированию, на котором рецензенты представляют свои выводы (сделанные перед собранием!) Автору. Это повысит мотивацию как юниоров, так и членов команды.