Легко поддерживать корпоративную культуру на словах. Однако лишь немногие компании активно изучают те немногочисленные особенности корпоративной культуры, которые оказывают существенное влияние на производительность, — потому что это самое сложное.
Для команд, создающих программное обеспечение, важнейшим прогнозным фактором инженерного благополучия, несомненно, является владение кодом. В этом практическом руководстве мы проанализируем именно то, как вам внедрить этот принцип в повседневную работу своей команды разработчиков, чтобы благополучие вашей кодовой базы поддерживалось само собой.
Мне посчастливилось встречаться с одними из лучших в мире разработчиков — в Stepsize я работаю с ними каждый день. И в ходе обсуждений того, как создаётся технический долг, с ведущими разработчиками таких компаний, как Skyscanner, Spotify, Palantir и др., неизменно поднимается один вопрос: владение.
В тесно взаимодействующих, быстро развивающихся командах (ну, т.е. в современных командах), где разработчики могут коммитить в любую часть кодовой базы, код легко захламляется и становится чудовищем, похожим на Франкенштейна. И когда дела становятся достаточно плохи, кто-то должен вмешаться, подобно Капитану Марвел, и поправить всё одним большим рефакторингом.
Чтобы избежать подобной ситуации, команды разработки пытаются придерживаться одного из многих замечательных советов Роберта С. Мартина («Дядюшки Боба»), а именно «правила бойскаута»: оставь код в лучшем состоянии, чем он был до тебя. Вот бесплатное расширение для VSCode, которое поможет вам сделать это намного легче.
Тем не менее, невзирая на уровень мастерства и лучшие побуждения разработчиков, похоже, будто непреложный закон разработки программного обеспечения состоит в том, что технический долг накапливается — до тех пор, пока его не становится слишком много, и тогда нам приходится выкраивать время для большого рефакторинга. Мы неохотно приняли это как часть жизненного цикла разработки программного обеспечения.
Может быть, всё сводится просто к недостатку дисциплины?
Так я думал раньше. А затем я встретил Гарета Визаджи, главного архитектора в Snyk.io, и он поразил меня следующей фразой:
Владение — вот главный показатель инженерного благополучия.
Что он имел в виду? И как он мог сделать такое заявление?
Существует огромный объем исследований, показывающих, что когда члены команды владеют плодами своего труда, отвечают за них перед менеджерами и берут на себя ответственность за успехи и неудачи, начинают происходить всякие хорошие вещи.
К сожалению, добиться такого на практике непросто. Отчасти потому, что, по-видимому, инженерная продуктивность не может быть измерена, и современные практики разработки можно рассматривать как в любых обстоятельствах поощряющие слабое владение кодом. Правда в том, что до настоящего момента было невероятно сложно правильно измерять владение в командах разработчиков… так что мы даже не знали, как выглядит «хорошо» для данного показателя.
К счастью, недавнее научное исследование показало, что владение кодом — наилучший косвенный показатель туманного понятия «владения» в командах разработчиков — может быть измерено по активности коммитов Git. И это замечательный опережающий показатель благополучия вашей кодовой базы.
Те части кодовой базы, в которые вносят изменения множество разработчиков, со временем захламляются, а те, с которыми работает меньшее количество людей, обычно находятся в лучшем состоянии. Не верьте на слово мне — хорошие люди из Microsoft изучили это на своем собственном примере.
Источник: исследование Microsoft
Я уже почти слышу, как некоторые из вас кричат, что вы не хотите ситуации, когда лишь один разработчик является тем единственным человеком, кому разрешено трогать какой-либо кусок кода — у такого подхода ужасные побочные эффекты. Я вас понимаю, и это не то, что мы предлагаем.
Дослушайте меня до конца.
Формы владения кодом
Существуют различные формы владения кодом, подходящие для разных обстоятельств.
Коллективное владение и отсутствие владения
Коллективное владение (collaborative ownership) —[…] владение, при котором код находится в совместной собственности, но обязанности и графики четко определены. Каждый член команды может работать над любой подсистемой или сервисом, если это необходимо.
Отсутствие владения (non-ownership) —[…] ситуация, в которой несколько разработчиков вносят изменения в одну и ту же подсистему, но координация действий, ответственность за качество или внутрикомандная коммуникация минимальны. В подобных системах не стоит ожидать высокого качества работы.
Источник: исследование Microsoft
Можно продолжить это разбиение дальше, добавив до кучи также бесхозный код и единоличное владение, но я не хочу упускать главное, так что вот график, демонстрирующий спектр форм владения кодом:
Коллективное владение должно быть вашим выбором по умолчанию и той формой владения, к которой вы должны стремиться. Заметьте, это не значит, что только у одного разработчика в вашей команде есть разрешение на изменение кода, или что любая модификация кода требует его одобрения. Это лишь означает, что каждому в команде совершенно ясно, с кем ему следует обсудить любые возникшие у него вопросы, и что владелец кода, скорее всего, лучше всех справится с выполнением рецензирования кода (code review). Это позволит каждому в команде повысить стандарты написания кода и осведомленность о том, как был модифицирован его собственный код.
Владелец отвечает за состояние своего кода, и менеджерам следует спрашивать это с него. Это не значит, что его нужно лупить по голове за каждый баг, просочившийся в его код; это означает, что владельцы уполномочены принимать решения, касающиеся качества кода и технического долга; на них будет возложена ответственность за эти решения с помощью дополнительных вспомогательных метрик, таких как связность (cohesion) и повторяющаяся активность (churn) (подробнее в нашей статье о метриках технического долга).
Отсутствие владения, или слабое владение (weak ownership), — это противоположность коллективного владения, и в большинстве случаев этой формы владения следует избегать. Как уже было сказано (и это, возможно, прозвучит очевидно) для файлов вроде package.json не иметь четко определенного владельца — нормальная ситуация. Впадать в крайности не нужно.
Бесхозный код (orphaned code)
Самый неприятный тип отсутствия владения, один из краёв спектра форм владения кодом. Такая форма владения вам точно не нужна. Избегайте ее любой ценой… если это, конечно, не код, который вы никогда больше не будете трогать. Но такой код встречается весьма редко.
Код рассматривается как бесхозный, если его главный разработчик прекратил вносить любые изменения в кодовую базу. Может быть, он покинул организацию, а может, перешел из разработчиков в менеджеры. В любом случае у вас серьезные проблемы — и у вашей кодовой базы тоже.
Однако и здесь есть решение. Вам нужно перевести исходный код в любую другую форму владения, наиболее для него подходящую. Чтобы избежать появления какого-либо бесхозного кода в вашей кодовой базе, убедитесь, что ваши планы на случай увольнения или передачи дел предусматривают введение в курс дела новых владельцев кода его старым владельцем. Вы можете облегчить им этот процесс, автоматически назначая их для просмотра пулл-реквестов на изменение кода. При отсутствии таковых, вы просто можете назначить владельцев кодом так, как считаете нужным.
Вне зависимости от того, какой метод вы выберете, не оставляйте бесхозный код болтаться в вашей кодовой базе. Никогда не знаешь, что с ним произойдет, если оставить его на произвол судьбы.
Единоличное владение (absolute ownership)
Это другой край спектра форм владения кодом. С ним все может быть как замечательно, так и очень непросто.
Код рассматривается как находящийся в единоличном владении, когда владелец — это единственный разработчик, который может вносить или одобрять изменения в код, или когда владелец — это, в сущности, единственный человек, кто когда-либо в прошлом вносил изменения в код.
Небольшие стартапы часто встречаются в своей работе с подобной практикой. Каждый разработчик, как правило, отвечает за всю историю отдельно взятого файла, и ожидается, что за ним сохраняется владение этим файлом. Это не конец света; у стартапов, в конце концов, ограниченные ресурсы, и нужно идти на определенные жертвы. Но если однажды разработчика переедет автобус, эта часть кода окажется бесхозной. Для подобных ситуаций у вас должен быть запасной план.
В более крупных инженерных организациях низкий «фактор автобуса» может быть настоящей проблемой, особенно если дело касается критически важных частей кодовой базы, текучка кадров высока, а технический долг, набранный компанией, слишком велик. Например, если уйдет разработчик, который сварганил всю вашу вручную настроенную систему платежей, у вас будет огромная головная боль — в случае, если вы захотите изменить свою модель ценообразования, или если вы обнаружите в его кодовой базе баг, из-за которого вы в течение многих месяцев недополучали деньги от своих крупнейших клиентов. Тогда либо кому-то нужно будет собраться и попытаться понять код для внесения в него изменений, либо вам придется объявить техническое банкротство по вашей платежной системе и переписать её с нуля (но перед тем, как делать это, пожалуйста, прочтите вот это).
Не дайте такому приключиться с вами.
Однако бывают случаи, когда единоличное владение кодом приемлемо или даже рекомендовано. Вы, возможно, захотите установить эту форму владения для тех частей кодовой базы, для которых верно утверждение «если эта часть сломается, мы можем сворачиваться, так как тогда бизнес не сможет выплачивать нам зарплаты или же мы отправимся в тюрьму».
В подобных случаях, даже если для поддержания достаточно высокого фактора автобуса вы хотите распространить знания о критической части кода среди нескольких разработчиков, вы, вероятно, захотите также установить правила, запрещающие без одобрения единоличного владельца соответствующего кода вливать пулл-реквесты.
Итоги
Стремитесь к коллективному владению для подавляющего большинства файлов в вашей кодовой базе (50%—90% владения кодом для любого отдельно взятого файла), и будьте более дисциплинированы для увеличения владения кодом и снижения технического долга, когда это необходимо.
Выгоды следующие:
- Более высокие и должным образом поддерживаемые стандарты написания кода. В небольшой, хорошо информированной группе придерживаться высоких стандартов проще. Это применимо не только к разработчикам, изменяющим свой собственный код, но также и к рецензированию кода (code review), написанного их коллегами и затрагивающего те части, которыми они владеют.
- Облегчение коммуникации. Явное и четкое владение означает, что каждый разработчик в команде знает, кто наилучшим образом ответит на его вопрос.
- Более сфокусированный и результативный рефакторинг. Если вы решили погасить часть технического долга, для этой работы лучше всего подходят сильные разработчики, владеющие соответствующим кодом. Используйте метрики владения, связности и повторяющейся активности, чтобы очертить проблемные области в вашей кодовой базе. Ваши разработчики будут с умом использовать свой бюджет технического долга и никогда больше не потратят время на погашение технического долга, который этого не стоит.
- Фактор автобуса никогда не выйдет из-под контроля. Можете использовать владение кодом для организации обмена знаниями в организации. Если степень владения слишком высока, назначьте других разработчиков на рецензирование кода и задачи, связанные с его изменением. Вы постепенно улучшите свои показатели владения, что приведет к повышению качества кода и уменьшению технического долга.
Как и все по-настоящему стоящее, создание инженерной культуры владения кодом (и следование ей!) требует времени и усилий, но они окупятся с лихвой. Этот фактор напрямую влияет почти на любой KPI инженерного благополучия, который вы только можете себе представить. Встройте его в культуру вашей компании, и в долгосрочной перспективе это станет вашим огромным конкурентным преимуществом.
