Предоставляйте лучшее программное обеспечение быстрее.
да. Это кликбейтный заголовок. Позвольте мне немного пояснить: то, как большинство команд разработчиков, которых я знаю, проводят проверку кода, вредно для выпуска качественного программного обеспечения.
Здесь нужно ответить на многие вопросы. Что такое проверка кода? Что такое качество программного обеспечения? Что такое «доставить»? И если обзоры кода настолько плохи, должна ли быть альтернатива? Если так, то, что это? Давайте исследовать.
Что такое проверка кода?
Проверка кода начинается с уведомления от локального инструмента управления версиями о наличии «запроса на включение» или «запроса на слияние», который кто-то хочет, чтобы вы просмотрели. Также может случиться так, что вы получите сообщение от коллеги с просьбой о проверке или возьмете один из рабочих элементов, которые оказались в столбце «На проверку» на вашей доске [вставьте agile-вариант здесь].
Неважно, какой из этих вкусов вас отталкивает. Общим здесь является то, что другой разработчик работал над чем-то, а затем, прежде чем работа будет запущена в работу (или «в производство»), останавливает свою работу над элементом и передает его коллеге. Это может быть конкретный (группа) коллег(ов) или общий, например, «Я выставляю это на рассмотрение всем, у кого есть на это время».
Затем, когда рецензент находит время, он находит фрагмент кода, созданный коллегой, и просматривает его. Рецензент оставляет комментарии создателю кода для последующей обработки (или отклонения). Это может повториться пару раз, прежде чем все будут довольны. Когда все вовлеченные разработчики довольны, изменение интегрируется в основную ветку исходного кода приложения, и все готово. Счастливые дни.
Вот как выглядит код-ревью в большинстве команд, с которыми я работал. Я назову этот тип проверки кода «асинхронной и блокирующей».
Что такое качество программного обеспечения?
В каждой среде и сфере деятельности качество означает что-то свое. Если вы создаете веб-сайт для поддержки телешоу в течение одного сезона, а после этого веб-сайт будет выброшен, вам не нужно легко добавлять множество новых функций. Если вы создаете программное обеспечение, которое управляет денежным потоком для банка, вы можете убедиться, что все имеет двойную или тройную отказоустойчивость. Я не собираюсь привязывать вас к одному из этих сценариев.
Качество, о котором я думаю, находится на другом уровне. На этом уровне более общее определение качества программного обеспечения можно найти по количеству производственных проблем, среднему времени устранения производственных проблем, времени выхода на рынок и даже моральному духу разработчиков (что, в свою очередь, ускоряет разработку и снижает заболеваемость и/или недомогание разработчиков). или уход из команды).
Что такое поставка программного обеспечения?
Вероятно, это определение вызовет больше всего споров: программное обеспечение поставляется только тогда, когда оно находится в производстве. Если программное обеспечение «принято и ожидает одобрения владельца продукта», оно не доставлено. Итак, по моему определению, если вы отправляете свой код на проверку другим разработчикам, он еще не доставлен.
И поскольку единственным мерилом прогресса является фактическая поставка программного обеспечения, это большое дело.
Проверка кода — это плохо
Описанный выше асинхронный и блокирующий код-ревью — это плохо.
Проверка асинхронного и блокирующего кода — это этап. Другими словами, он блокирует поток функции или улучшения, над которым вы работаете, до тех пор, пока не произойдет внешнее событие, проверка кода. Вы должны перестать работать, ждать кого-то еще, а потом они снова должны ждать вас. На мой взгляд, это очень похоже на повторное внедрение метода водопада. И мы только что освоили всю эту гибкую штуку, верно? Правильно? Мы также определили качество отчасти как время выхода на рынок: время между идеей и поставленным программным обеспечением, необходимое для того, чтобы эта идея расцвела. Ворота, которые необходимо сохранить, в данном случае проверка кода блокировки, удлиняют это время.
Давайте подробнее рассмотрим процесс асинхронного обзора. Когда вы закончите работу над кодом и предложите код для проверки кода, вы больше не сможете над этим работать. Что вы делаете в это время? Начать работу над чем-то другим? Проведите предварительное исследование отчета об ошибке? Как много времени это займет? Час? День? В командах, которые я видел на протяжении многих лет, коллеге требуется от часа до двух дней, чтобы найти время в своем собственном расписании для проверки вашего кода. Это переключатель фокуса для вас. Для них тоже. Затем, когда ваш коллега закончит проверку, вы должны вернуться к коду, который вы отправили. Еще один переключатель фокуса.
Не знаю, как у вас, а у меня переключение фокуса требует времени. Даже если это прерывание на 1 минуту, мне требуется много времени, чтобы снова полностью сосредоточиться и понять предыдущий вопрос. Асинхронный переход туда и обратно по коду, открытому для проверки, съедает время и оставляет нас открытыми для упущения контекста, когда мы возвращаемся к коду, который находится на проверке. Ваш рецензент не знает, почему вы так решили задачу. И, может быть, через день или два вы тоже этого не сделаете. Ваш рецензент может не найти действительно сложных частей или частей, которые были особенно сложными и поэтому заслуживали тщательного рассмотрения.
Конечно, вы можете все это исправить, оставив много-много комментариев и инструкций для ознакомления. Но я считаю, что есть лучший способ сделать асинхронный и блокирующий обзор кода устаревшим.
Лучший вариант: парное программирование
Мы стремимся уменьшить количество гейтов, уменьшить переключение фокуса и улучшить понимание (и, следовательно, качество) кода.
Я признаю необходимость политики «четырех глаз». Я не думаю, что это хорошая идея запускать код в производство, когда на него смотрела только одна пара глаз. Это увеличит количество производственных проблем. Это также уменьшает количество людей, понимающих код, что увеличивает затраты времени на исправление производственных проблем и восстановление после них: это снижает качество кода. Поэтому отказ от совместной работы над кодом — не то решение, которое мы ищем.
На протяжении многих лет я внедрял парное программирование и использовал его как альтернативу асинхронным и блокирующим проверкам кода. Когда вы создаете код вместе, вы используете силу двух разумов, создающих код. Один на (буквальном) практическом уровне работы с компьютером, другой следит за более высоким уровнем и придерживается курса на решение, которое вы создаете. Вы можете пробовать и отвергать идеи сразу, вместе. Это звучит как встроенный код-ревью прямо здесь. И вы получаете автоматический обмен знаниями бесплатно.
да. Парное программирование сложно и утомительно. Чтобы делать хорошо, нужна практика. И да. Возможно, ваша команда согласится с тем, что для некоторых незначительных изменений вы не хотите возиться с политикой очкарика. Это правильный выбор для менее рискованных изменений, если дефект в вашем программном обеспечении не означает, что люди умирают или компания теряет кучу денег. Проблема, конечно, заключается в том, чтобы заранее решить, что такое «менее рискованное изменение». Если вы решите сделать это различие, ваша профессиональная ответственность и ответственность вашей команды — активно совершенствовать свой радар для «менее рискованных изменений». Обсудите это при планировании работы. Не ищите здесь серебряную пулю или алгоритм, который может обнаружить «менее рискованные изменения» для вас. Это то, что делает вас ценным человеком в сфере технологий и гарантирует, что разработчики программного обеспечения не останутся без работы в ближайшем будущем.
Когда код-ревью имеет смысл
Есть случаи, когда проверка кода имеет смысл или является обязательной, или и то, и другое. Если вы вносите свой вклад в открытый исходный код с присущим ему асинхронным характером сотрудничества, поскольку большинство вовлеченных людей будут иметь разные часовые пояса, расписания и пики производительности, которые необходимо учитывать, то асинхронные и блокирующие проверки кода на основе запросов на вытягивание имеют смысл. Они подходят туда. Если вам нужно пройти определенную сертификацию безопасности, которая требует явной и блокирующей проверки кода, альтернативы нет. Однако это не означает, что это улучшает вашу способность создавать качественное программное обеспечение.
Кроме того, вы по-прежнему можете проводить неблокирующие проверки кода. Я часто выделяю запланированное время с коллегой, чтобы продемонстрировать изменения, которые мы уже внедрили в производство. Из любопытства, из заботы и чувства ответственности за программное обеспечение, а также из профессионального интереса к изучению новых способов решения проблем я хочу узнать, как мой коллега решил проблему. Этот запланированный обзор кода не блокирует: все изменения уже внесены, и мы явно выбрали момент, который не мешает нам сосредоточиться. Он также синхронен: он позволяет нам думать о коде вместе одновременно, вместо того, чтобы асинхронно переходить туда и обратно. Во время проверки кода, подобной этой, мы также регулярно выявляем улучшения и реализуем их. Это большая часть нашей ответственности как разработчиков: поддерживать высокое качество программного обеспечения.
Наконец, я постоянно пытаюсь просмотреть весь код, который я вижу и к которому прикасаюсь. «Правило бойскаута» говорит мне оставить лагерь (или, в данном случае, кодекс) чище, чем я его нашел. Одна из причин, по которой ревью блокирующего кода может занять целую вечность, — это ощущение, что «если мы не исправим все проблемы сейчас, они никогда не будут исправлены позже». Вместо того, чтобы удваивать блокирующий обзор кода, попробуйте очистить код, с которым вы сталкиваетесь во время работы, даже если он не имеет прямого отношения к тому, над чем вы работаете. Когда вы питаете уверенность в том, что код будет регулярно изменяться и постоянно улучшаться, вам не нужно беспокоиться о блокировке отзывов.
В итоге
Выберите активную совместную работу над решениями, а не блокирующий подход на основе запросов на вытягивание для обеспечения качества кода и программного обеспечения. Парное программирование и практика постоянного улучшения всего кода, к которому вы прикасаетесь, улучшит качество вашего программного обеспечения и процесс доставки.
