Автоматического тестирования недостаточно, и его необходимо дополнить экспертной оценкой.
Разработка программного обеспечения не становится проще. В настоящее время кажется, что любое приложение должно быть облачным, управляемым событиями и обеспечивать высокий уровень масштабируемости и отказоустойчивости.
Следствием этого сценария является то, что этап проверки кода вашего жизненного цикла разработки становится все более сложным из-за широкого объема знаний и более важного выявления ошибок.
К сожалению, при отправке и проверке кода легко упустить из виду то, что важно. Я расскажу о некоторых распространенных ловушках, с которыми я столкнулся, и о том, на чем следует сосредоточиться, чтобы улучшить процесс проверки.
Это не пулл-реквест, это рецензирование
Программное обеспечение для контроля версий (VCS) практически вездесуще в нашей индустрии, но некоторые могут даже не узнать его из-за популярности git, ставшего чуть ли не синонимом.
Github популяризировал термин запрос на вытягивание, когда у вас есть способ сообщить другим разработчикам, что вы создали новую ветку, соответствующую новой версии вашего исходного кода. Затем другие могут увидеть различия и прокомментировать их, в конечном итоге одобрив или отклонив слияние ваших изменений с основной веткой.
Теория, лежащая в основе этого, заключается в том, что, давая другим возможность взглянуть на предложенные вами изменения, они могут обнаружить ошибки, которые вы пропустили, до того, как они будут запущены в производство.
На самом деле идея PR — как и в экспертной оценке — также служит механизмом обмена знаниями для других членов команды. Учитывая вышеупомянутую сложную ландшафтную разработку программного обеспечения и частое внедрение agile/scrum, вы не можете позволить себе разрозненность, когда только один человек способен понять ваш код.
Вы должны убедиться, что вы воспринимаете любой PR как возможность поделиться знаниями, от прямого выбора кода до бизнес-правил, которые они должны зафиксировать.
Общие ловушки
Давайте посмотрим, знаком ли вам следующий сценарий:
Джон — разработчик, и он целую неделю работал над добавлением новой функции в наш продукт. Он создает PR-запрос из 55 файлов, и его никто не проверяет пару дней.
После третьего обращения за помощью он либо получает один из двух типов обратной связи:
- 3 комментария по выбору имен переменных, предложение использовать forEach вместо цикла for и LGTM в конце
- Один комментарий, описывающий, как функция/интеграция/абстракция неверны и требуют серьезного переписывания.
В первом случае Джон сливает свой код, и теперь его коллегам придется исправлять свои ветки из-за количества внесенных им изменений. Также из-за этого они не могут финишировать вовремя и цель спринта не достигается.
Во втором случае Джону нужно учесть все изменения, но поскольку спринт почти завершен, времени на слияние не будет, а цель спринта не будет достигнута.
Конечно, пример был создан как гипербола, но он не так далек от обнаруженной там реальности.
Давайте разберем сценарий и посмотрим на потенциальные проблемы и их последствия.
1. "Отработал целую неделю"
Ваш случай может быть другим, но одна неделя может быть долгим временем, прежде чем вы получите какой-либо отзыв. Многое может измениться или пойти не так, прежде чем кто-то успеет взглянуть.
Если ваша работа является частью непосредственных командных целей, вы можете поставить под угрозу результат либо потому, что другие выбрали другое направление и им приходится приспосабливаться к вашему, либо наоборот.
2. 'Создает запрос PR с 55 файлами'
Скорее всего, это следствие работы в течение длительного периода в изоляции, но когда у вас есть большое количество изменяемых файлов и/или строк кода, качество обзора резко снижается.
Существует известное исследование, которое указывает на то, что качество проверки падает по мере увеличения количества строк кода, подлежащего проверке.
Это имеет двойной эффект. Поскольку объем изменений слишком велик для понимания рецензентом, у него возникает соблазн сместить акцент с правильности решения, касающегося бизнес-требований, на стиль кода.
Что еще хуже, знания, которые мог бы получить рецензент, скомпрометированы из-за изменения фокуса.
3. "Пару дней никто не рецензирует"
После того, как PR был создан, автор пошел дальше и сейчас занимается другой частью разработки. Это означает, что его мышление сосредоточено на другом контексте, чем тогда, когда PR был отправлен.
Это означает, что вам потребуется больше времени, чтобы ответить на отзыв, особенно если он был значимым или оказал большее влияние.
Как мы видим, есть проблемы с обеих сторон, со стороны тех, кто отправляет PR, и тех, кто выполняет проверку. Давайте обсудим, как улучшить.
Улучшение процесса проверки
Прежде чем предпринимать какие-либо конкретные действия, на что мы обращаем внимание, когда хотим улучшить процесс проверки?
Для меня это, по сути, означает возможность:
- Уменьшить количество ошибок, внесенных в основную ветку
- Уменьшить случайный технический долг, накопленный
Из всех обсуждаемых практик, вот список основных, которые должны быть приняты автором и рецензентом.
Автор
Держите ваши PR небольшими
Не существует идеального количества файлов или строк кода, поскольку языки и контекст будут сильно различаться, но идея состоит в том, чтобы разбить любое изменение на более мелкие, автономные части функциональности.
Если возможно, рассмотрите подход вертикального разделения, когда PR предоставляют все более полные функции. Помимо прочих преимуществ, они облегчают понимание рецензентом.
Предложение, которое может сработать для вас, состоит в том, чтобы установить временные рамки для этого. Я рекомендую своим командам учитывать правило 3–4 часа, особенно в начале разработки. По прошествии этого времени у вас должно быть достаточно кода, который выиграет от обзора.
Проверьте свой код перед созданием PR
Мы все делаем ошибки, и я всегда нахожу способы улучшить или исправить свой код, если взглянуть на него через некоторое время.
Совет: сделайте небольшой перерыв, выпейте свой любимый напиток, сделайте паузу на обед или сделайте обзор чужого кода. Ключ в том, чтобы сосредоточиться на чем-то другом, а затем перечитать свой код.
Если у вашей команды есть контрольный список общих аспектов, используйте его, в противном случае создайте свой собственный. В конце концов, следует акцентировать внимание на четкости, соблюдении стандартов и корректности.
После того, как вы обратились к своим выводам, создайте PR и добавьте хорошее описание.
Определите, что, почему и что будет дальше в PR-описании
Как автор PR, то, что вы сделали, ясно, по крайней мере, некоторое время после его отправки.
Вашему рецензенту понадобится какой-то контекст, и распространенная ошибка, которую я вижу, даже когда PR невелики, заключается в том, что рецензент может недостаточно понимать масштаб, чтобы изучить или оценить решение.
За исключениями, я рекомендую, чтобы ваше PR-описание содержало как минимум следующие разделы:
- Каков объем этого PR — Обычно это означает краткое описание того, чего вы пытаетесь достичь.
- Зачем нужно это изменение. Если вы исправляете ошибку или корректируете код, чтобы отразить новый набор требований, это поможет обмену знаниями и оценке решения.
- Что дальше — вы хотите подсказать рецензенту, чего он не найдет в этом PR, и вы можете указать это в этом разделе.
Рецензент
Сосредоточьтесь сначала на ясности и правильности, а затем на стандартах
Если есть понимание масштаба PR, следует в первую очередь посмотреть, правильно ли он решает ту задачу, для решения которой предназначен. Мне трудно отделиться от ясности, которая идет от четко названных вещей (переменных, функций, классов и т. д.) к выбранному пути выполнения.
Как только вы это поняли, чему может помочь просмотр тестов, вы можете переключиться на соблюдение стандартов. Под стандартами здесь подразумеваются в основном набор кодовых и архитектурных практик, которые есть у вашей команды/домена, а не, например, линтинг.
Основывайте свой отзыв
PR — это двунаправленная возможность обучения. Если вы дадите положительный или отрицательный отзыв, постарайтесь предоставить какое-то объяснение, которое даст автору больше информации, чтобы понять, почему ваш вопрос (потенциально) актуален.
Не бойтесь задавать вопросы
Если вы недостаточно понимаете контекст/код, у вас может возникнуть соблазн оставить вопросы при себе и сосредоточиться на простых вещах (важное, но изменение названия).
Не сдерживайтесь, если вы уважительно изложите свой вопрос, это будет лишь сигналом того, что то, что было так очевидно автору, не так уж и много!
Заключение
Сложность и скорость, с которой мы должны предоставлять новые функции, возрастают. Автоматического тестирования недостаточно, и его необходимо дополнить экспертной оценкой.
С популярностью GitHub мы все привыкли создавать PR, но часто можно увидеть, как обзоры закрываются, не достигнув ожидаемой цели.
Помните, что это возможность обучения для всех, и что мы должны сосредоточиться на том, чтобы максимально использовать ее.
Советы, данные как автору, так и рецензенту, просты, но требуют определенной дисциплины.
Если у вас есть дополнительные идеи, поделитесь ими в разделе комментариев.
