PR: сдвинься влево, пожалуйста (часть вторая)

Реалии PR-процесса

В предыдущей статье PRs: Shift Left, Please (Part 1) я утверждал, что сам процесс запроса на вытягивание (PR) по своей сути неэффективен и неэффективен. Акцент на сведении к минимуму человеческого взаимодействия ставит процесс PR на самое правильное место по шкале от предпочтения отдельных лиц и взаимодействий до предпочтения инструментов и процессов:

Таким образом, процесс PR по определению не является гибким. "Ну и что?" вы отвечаете. В этой статье я рассмотрю «что» относительно реалий процесса PR, которые:

может разрушить вашу культуру
по своей сути неэффективен
по своей сути неэффективен

PR может разрушить вашу культуру

Человеческое взаимодействие — сердце Agile — это то, где происходит истинное общее понимание. Когда мы взаимодействуем в режиме живого обзора кода, задавая вопросы и отвечая на них, мы можем быстрее всего добраться до точки, когда все знают, что делает код и почему он был написан таким образом. Это улучшенное понимание повышает качество обзора — у нас больше шансов обнаружить дефекты, мы лучше понимаем уместность дизайна решения, и нам легче давать рекомендации по улучшению ясности кода и другим аспектам дизайна (чтобы снизить стоимость). изменения).

Человеческое взаимодействие — сердце Agile — это то, где происходит истинное общее понимание.

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

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

Однако на письменном форуме комментарий, истолкованный как оскорбительный (независимо от того, думал ли он об этом рецензентом или нет), может некоторое время гореть, если его не разъяснить должным образом. Иногда рецензент обижается, что обиделся человек, написавший код, и в этом случае обе стороны могут чувствовать себя в команде менее защищенными. Это снижение уровня коллективного доверия команды может снизить ее эффективность. В результате мы учимся тратить дополнительное время на тщательную формулировку вопроса или комментария, что, в свою очередь, увеличивает неэффективность и отвращение к процессу PR.

PR по своей сути неэффективны

Мы делаем PR, чтобы выявлять дефекты и улучшать наш код, чтобы снизить затраты. Но они плохо справляются с обеими задачами — мы лишь незначительно повышаем качество кода и не устраняем достаточное количество дефектов.

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

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

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

Даже когда мы вкладываем душу в реагирование на PR, мы все равно можем упустить более глубокие, важные проблемы дизайна — отчасти потому, что мы упустили глубокие обсуждения и решения, которые другие превратили в сложный набор изменений кода.

PR по своей сути неэффективны

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

Из-за стоимости еще одного перерыва мы откладываем. Мы предпочитаем получать PR, когда мы между задачами или в конце дня. В результате мы либо:

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

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

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

Ранее я обсуждал неэффективность механизма комментариев (мы тратим дополнительное время на то, чтобы комментарии не могли быть восприняты неправильно). Этот механизм также обычно увеличивает затраты, потому что эффективная письменная беседа почти никогда не бывает такой же быстрой, как устная беседа, отчасти потому, что ее цикл обратная связь и правильность слишком длинный. Затянувшийся обмен механизмом комментирования PR также создает больше перерывов между задержками.

Согласно моему заявлению об эффективности из предыдущего раздела, большинство проблем, о которых сообщалось во время обзора PR, являются поверхностными дефектами. Запрашивающая сторона исправляет ошибки в отчете, а затем повторно запрашивает проверку. После повторной проверки код интегрируется, если не будет обнаружена другая проблема (независимо от того, была ли она только что создана или пропущена ранее).

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

Цикл код/проверка/переписывание/перепроверка неэффективен. И код/ревью/выпуск-плохого-кода неэффективны, хотя это происходит чаще, чем мы хотели бы признать.

Совместное развитие

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

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

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

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

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

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

«Но мы не можем делать синхронно»

Если ваша команда остается в значительной степени распределенной, пул-реквесты все еще могут показаться подходящими. Если это так, вы обязаны перед своей командой начать определять, насколько они ценны на самом деле, учитывая их стоимость. Начните собирать некоторые реальные данные (но помните, что многие нематериальные факторы затруднят получение полной картины):

Сколько человеко-часов вы на самом деле инвестируете в процесс? Учитывайте время, которое люди тратят на чтение и рассмотрение запроса, а также время, которое исходный разработчик тратит на ответы на комментарии и внесение изменений.
Насколько эффективны пулреквесты? Начните измерять количество обнаруженных дефектов по сравнению с количеством обнаруженных позже (сдерживание). И найти способ оценить стоимость каждого дефекта, который ускользает от производства.
Каково время выполнения изменений (LTC)? Эта метрика DORA измеряет время между фиксацией кода и временем, когда вы можете запустить его в производство, и является ключевым показателем эффективности вашей команды.
Насколько хорош код? Хотя трудно подсчитать реальные цифры, постарайтесь измерить любое увеличение стоимости изменений, когда вы имеете дело со сложным кодом. Помогают ли отзывы снизить эти расходы?

Хотя это обычно невозможно для распределенных команд, большинство из них время от времени накладываются друг на друга. Вместо отправки PR найдите способ подключиться к Интернету или вживую (когда люди дышат в пределах досягаемости друг друга) и сделайте интерактивный обзор, возможно, используя дисциплинированный процесс, такой как инспекции Фагана. Убедитесь, что вы собираете данные о процессе и адаптируете их соответствующим образом! Наконец, рассмотрите возможность формирования большинства ваших команд на основе их способности работать синхронно — это дает множество других преимуществ.

Сдвиг влево

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

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

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