Я большой поклонник обзоров кода и тех преимуществ, которые они предоставляют. Проверка кода - важная часть жизненного цикла программного обеспечения, как автоматизированная, так и индивидуальная. Они могут способствовать распространению знаний, выступать в качестве проводника для наставничества, находить ошибки до того, как они попадут в рабочую среду, и т. Д. Одно из моих любимых исследований по этой теме - здесь с Международной конференции по разработке программного обеспечения 2013 года.
К сожалению, ревью кода также может стать проблемой. У них есть привычка создавать конфликты между разработчиками из-за больших и малых проблем. Они часто отнимают драгоценное время и являются узким местом в рабочем процессе команды. Кроме того, поскольку большинство проверок кода происходит через Интернет, комментарии вырываются из контекста, и вы быстро обнаруживаете, что два разработчика становятся врагами вместо того, чтобы работать вместе.
Когда два разработчика начинают заниматься этим в обзоре, вы теряете все преимущества обзора. Повторяю: все. Если вы натолкнетесь на врага со своим товарищем по команде из-за обзора (независимо от того, являетесь ли вы рецензентом или автором), доверие и безопасность будут потеряны. Когда эти две вещи потеряны, команды, по данным исследований Google, просто не будут работать хорошо.
Как старший член моей команды, я часто пишу обзоры. Таким образом, я столкнулся с множеством ошибок и извлек много уроков о проведении и эффективном рассмотрении. Многие из них больше связаны с менталитетом, связанным с обзором, чем с моей способностью читать код или находить ошибки. Мне пришлось научиться лучшим способам делиться своим мнением со смирением и уверенностью, одновременно пытаясь учить и наставлять, как могу.
Я ни в коем случае не идеален, но я верю, что то, что я узнал, может помочь вам наживать врагов из-за проверки кода.
Проверка кода - это понимание
Вся цель обзора кода - улучшить понимание. В документе, цитируемом в первом абзаце, это называется вызовом:
Из интервью ни одна другая проблема проверки кода не выявилась так ясно, как понимание представленного изменения. … В то же время в проанализированных нами комментариях по обзору кода вторая по частоте категория касается понимания.
Конечно, это вызов! Даже самый лучший написанный код может быть трудным для понимания. Борьба за понимание имеет первостепенное значение для эффективного обзора, а не сосредоточение внимания на обнаружении ошибки или проверке форматирования.
Когда я подписываю отзыв, я удостоверяюсь, что понимаю по крайней мере следующее:
- Цель или намерение пересматриваемых изменений кода (т. Е. Требования)
- Что изменения в коде фактически достигнут этих целей. Это, кстати, требует тестов ...
- Изменения кода сделаны таким образом, чтобы качество соответствовало стандартам кодовой базы.
Если каждый, кто занимается проверкой кода, будет подходить к нему с желанием понять и изучить, все остальное будет проще. Если вы сделаете это о поиске ошибок, вы позволите стилю идти своим чередом. Если речь идет только о стиле, вы упустите неправильные шаблоны. И так далее, и так далее.
Вам еще предстоит многому научиться
У вас есть чему поучиться каждый раз, когда вы участвуете в обзоре! Рецензент и автор. Помня об этом, каждый должен проявить некоторое смирение.
Смирение важно в любой сфере работы, но любая форма знаний особенно нуждается в нем. Буквально ни один человек не может знать все в мире разработки программного обеспечения. Они могут знать многое, но не все.
Если ваш рецензент оставит комментарии о лучшем шаблоне или распространенной ловушке, в которую вы попали, попросите дополнительную информацию. Попросите цитаты ссылок. Спросите пример кода. Истинное смирение при проверке кода восходит к намерению учиться и понимать. Реализация решения или предложения рецензента только «потому, что» лишает вас этого знания.
Точно так же, как рецензент, не стоит просто комментировать, как вы что-то закодировали! Есть много вариантов решения проблемы! Я многому научился, изучая и разбираясь в кодах других людей, которые я изучал. Когда вы все же оставляете отзыв - а вы должны! - будьте готовы объяснить, почему. Дайте цитаты и аргументы заранее. Предлагайте примеры и отрывки. А когда автор ставит под сомнение ваше мнение, это лучшее время оставаться скромным. Скоро произойдет обучение. Вот-вот появится лучшее решение. Но только если ты будешь скромным!
Знайте, когда говорить лично
В конце концов, все мы знаем, что общаться сложно. Общение в интернете еще хуже! Чтобы понять это, вам не нужна ссылка.
Когда разговор становится напряженным, вам нужно знать, что добавление еще одного комментария в запрос на перенос бесполезно. Вам нужно отвлечься от обсуждения кода и напрямую взаимодействовать с другим человеком. В идеале это означает личный разговор. Однако в стране удаленных команд и проектов с открытым исходным кодом лучшее, что вы можете сделать, - это видеоконференция.
Видеть друг друга очень важно! Есть исследования, согласно которым простое наблюдение за тем, с кем вы разговариваете (в цифровом формате или в реале), увеличивает вашу способность к состраданию и доверию.
Как только вы переведете разговор в автономный режим, вам сначала нужно убедиться, что вы оба начинаете с ровной поверхности. Если можете, уточните, в чем именно заключается ваше несогласие. Не обвиняйте кого-то в том, что он не читает или пренебрегает. Я даже обнаружил, что беготня по комментариям и их чтение вслух (да, вслух!) Многое проясняет само по себе.
После того, как вы найдете точки соприкосновения, продолжайте сосредотачиваться на обучении и оставаться скромным. Наилучший способ сделать это - задать вопросы: являются ли их требования в пользовательской истории бессмысленными? Есть ли недопонимание по поводу термина, который вы оба использовали в обзоре? Есть ли у кого-то плохой опыт работы с определенным паттерном из предыдущего проекта?
Оттуда вы можете приступить к решению проблемы. Не вы атакуете проблему, а не человека! На этом этапе цель состоит не в том, чтобы выиграть спор, а в том, чтобы понять, почему вообще существует разногласие, а затем работать вместе, чтобы найти хорошее решение.
Конечно, есть намного больше (и я, возможно, напишу второй раунд позже). Для получения дополнительных практических советов я настоятельно рекомендую этот список GitHub. Он ориентирован на Ruby, но есть отличные выводы за пределами специфических для языка частей.
В конце концов, чтобы не натолкнуться на врага во время обзора, нужно действовать как хороший товарищ по команде. Все вышеперечисленные идеи сводятся к этой идее. Это такое же искусство, как наука и техническое мастерство.
Удачного кодирования (и рецензирования)!
