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

Автор оригинала: Alexandre Omeyer
  • Перевод


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


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


Мне посчастливилось встречаться с одними из лучших в мире разработчиков — в 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 инженерного благополучия, который вы только можете себе представить. Встройте его в культуру вашей компании, и в долгосрочной перспективе это станет вашим огромным конкурентным преимуществом.

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 20

    +7
    Ты, говоришь, пишешь на Скале? Отлично, я назначаю тебя «владельцем» этих 30 миллионов строк на коболе, которые работают внутри эмулятора внутри виртуальной машины внутри виртуальной машины на вот том сервере устаревшей модели.

    Глафирий Порфирьевич собирается покидать нас, потому что у него, увы, здоровье не то и деменция уже совсем замучила. Он тебя по-быстрому введёт в курс дела, и ты будешь владельцем этого кода — принимать в него pull-request'ы от Акакия Варфоломеевича и Эры Валериевны.
      +1
      Есть более эффективная метрика для тех же целей — bus factor, сколько человек должен сбить автобус (условно покинуть команду), чтобы работа по проекту остановилась. Маленький bus factor — высокие риски, большой — высокие затраты, так как совместное владение кодом всегда дороже, чем единоличное. Если у вас хороший климат в коллективе и низкая текучка — можно стремиться к bus factor равному 2, то есть по каждому проекту/микросервису минимум 2 человека знают принцип работы и могут заменить друг друга в случае отпуска/увольнения/больничного. Мы в моей команде просто составляли табличку: проект, ответственный, дублирующий, и расписывали около 15 микросервисов на 5 человек. И для проекта хорошо, и разработчику дополнителный почёт, особенно для джунов, что они ответственны пусть за маленький, но собственный сервис.
        +2
        Есть более эффективная метрика для тех же целей — bus factor

        Вся статья как раз написана о том, что если маленький bus factor — это общеизвестное «плохо», то большой bus factor — это тоже плохо, вот только об этом никто не знает и не говорит.
        +7
        Легко поддерживать корпоративную культуру на словах.

        Когда я слышу слова «корпоративная культура», моя рука тянется к пистолету (почти (с)). Потому что слова эти — сигнал того, что идет обсуждение, как побольше состричь шерсти с простых разработчиков. И данная статья — не исключение.
        когда члены команды владеют плодами своего труда, отвечают за них перед менеджерами
        Слово «владеют» в предыдущей фразе — обманка. Плодами труда наемных работников в корпорации владеет корпорация, а не разработчики (не верите — попробуйте забрать с собой то, чем вы якобы «владеете»). А настоящий смысл фразы заключен во второй её части: разработчики — отвечают. Точнее, по мнению менеджмента — должны отвечать. Только вот реализовать это «отвечают» при новых методах организации разработки стало сложнее: потому что в борьбе с «человеческим фактором»(AKA bus factor) менеджмент довел процессы разработки до такого состояния, когда никто из разработчиков не контролирует целиком никакую часть написанного кода. То есть — код от разработчиков отчуждается уже в процессе написания программы, а не после её завершения.
        И вот меджемент нашел, как ему кажется, хороший способ решения проблемы — «коллективное владение». То есть, по факту — коллективная ответственность, иначе говоря — круговая порука. Когда за косяки одного отвечает «команда». В отношениях между человеком и государством такая форма ответственности считается жутчайшим анахронизмом и мракобесием. Про такое государство обязательно будет сказано и написано много нехороших слов. Но вот то, что не позволено государству, почему-то позволено (и даже считается хорошим и передовым) для корпорации. Парадокс?
        Спасает тут только то, что коллективную ответственность сложно формализовать. Делать это напрямую — вступать в конфликт с законом. А от всяческих попыток использовать косвенные показатели, типа предложенного в статье, спасает закон Гудхарта: если какой-то показатель начинает использоваться для управления, то эмпирическая закономерность, на которой это управление основано, перестает действовать. Потому что люди — не дураки, и способы, как сделать правильную отчетность без лишнего напряжения, они обычно находят и, причем — быстро.
          0
          «Драконы существа алчные и в драконьем языке сорок семь значений слова „мой“» /~какая-то фантошка/
          В русском слово «мой» тоже… многогранно: в случаях «моя шапка» и «моя родина» — слово «мой» имеет практически противоположные смыслы.
          Поэтому у меня лично в этом тексте никаких проблем слово «владеть [кодом]» не вызывает.
          Автор имеет в виду «кто наполняет модуль новым кодом и гарантирует корректность вставленного», только и всего. Здесь ни намёка на то, кому и как продаётся код, кем и зачем эксплуатируется.
          И несуразица с «коллективным владением» так же просто означает, что в пределах одного, например, файла, отметились несколько разработчиков. В большинстве ситуаций локализация бага до строки эквивалентно выводит на косячника. В меньшинстве ситуаций модификация одного провоцирует ранее скрытый баг другого, но это существенно реже и таки поддаётся локализации.
          Что касается ложных KPI или приспособления хитрого существа оптимизировать KPI вместо оптимизации производства, то да, проблема большая — мало кто может выразить разработку через некий релевантный цели index.
            +1
            В общем-то, по поводу этого конкретного текста я с вами согласен: конкретно в нем «владение» — это чисто технический термин в рамках технологии управления, краткое обозначение для делегирования отвественности и права принятия решений.
            «Но есть нюанс»(с) — слова «корпоративная культура» в заголовке. Корпоративная культура — она ведь имеет две стороны: включает в себя не только технологии организации производства, но и внутрикорпоративный PR — тоже. И именно в контексте PR слово «владеть» имеет нехороший оттенок: очень уж оно подходит, для того чтобы ездить по ушам наемным работникам, чтобы внушить им ложное чувство общности их интересов с интересами корпорации. И цитата «почти из Ганса Йоста» из начала, да и, собственно, весь мой первый комментарий как раз были навеяны этим самым нюансом.
            0
            Но вот то, что не позволено государству, почему-то позволено (и даже считается хорошим и передовым) для корпорации. Парадокс?

            Никаких парадоксов. У государства есть монополия, которой нет у каждой конкретной компании, сменить государство сильно сложнее, чем сменить компанию.

              0
              IMHO различие — по затратам на смену — чисто количественное. А качественно ситуация одна и та же: что государство, что корпорация значительно сильнее простого человека, и им значительно легче навязать этому человеку свою волю, чем наоборот.
          • НЛО прилетело и опубликовало эту надпись здесь
              +3
              А можно и проще. Как только кто-то меняет модуль (метод, класс, файл, каталог, проект целиком) — он становится полностью за него ответственнымю А то, понимаешь, написал ты милион строк. Пришел Вася, поменял десяток. Все упало непонятно как. Кто крайний?

              Я причем на полном серьезе. Именно так наша команда и работает — кто последний менял файл, тот за него и отвечает.… в теории.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  А если программа не компилируется, потому что у нее неправильно прописаны зависимости? Или вообще не прописаны? Или код в Github-репозитории не совпадает с кодом на сервере, потому что заливается на сервер напрямую из локальной папки разработчика?
                  Далеко не все проблемы можно свести к техническим.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Если в компании есть движение к DevOps — у нее все очень неплохо с корпоративной, управленческой и инженерной культурой. Об этом я и говорю. Если нет — техническими средствами это не решить.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0

                    Работал в команде, где было так принято.


                    В общем, баги там не чинились, люди просто писали нужные им функции-классы-библиотеки с нуля.

                      +3

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

                      0

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


                      И именно это я назову основным доводом в пользу микросервисов.

                      +1

                      Если подойти с точки зрения управления (поверхностно), то получается картина:
                      Делим проект на куски, каждому куску назначаем ответственного.
                      Вернее двух ответственных (помним про автобус)
                      Соответственно, каждое дополнение должно пройти через дополнительных двух человек (в случае, если изменяет у себя — через одного)
                      В принципе, нормально. Один написал, другой проверил.
                      Либо поверил на слово, но принял на себя ответственность.


                      • Надо ввести ввести отчётность — кто сколько новых кусков добавил и тоже ставить их на учёт.
                        То есть к выполнению задачи добавляется сразу ее проверка и только после — тестирование. При этом у нас идёт простой по времени между "сделал" и "проверили", соответственно увеличивается время выпуска продукта. В случае "коротких" задач (3 часа), мы можем надеяться, что правка будет принята завтра (проверяющий доделал задачу и переключился на проверку). В случае длинных задач, проверяющий будет выпадать из контекста, то есть работа с короткими задачами оптимальна. В принципе на скрам должно ложиться неплохо, особенно, если совместить с тестированием. Но с ним не совместить — качество и адекватность кода тестировщик не проверит.
                        Все таки добавляем ещё один столбик и таки двигаем время выхода продукта, либо уменьшаем количество фич в спринте.
                        Но при этом убиваем взаимозаменяемость в команде.
                        Но как бы добавляем качество.
                        Быстро, дорого, хорошо — выбираем дорого и хорошо. Это либо разработка с гарантированным качеством, либо подготовка к последующей поддержке по sla.
                        +1

                        Ну так собственно автор и пишет про дорого и хорошо. Понятно, что чем-то приходится жертвовать. Плохие практики они не просто так появились, они чаще всего или про быстро, или про дёшево. Тут вопрос в поиске баланса, как сделать сейчас дешевле, так что бы потом не сделать сильно дороже.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое