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

На своей должности руководителя разработки я стал непосредственным свидетелем разницы между командой, которой предоставили мощь и… какой антоним у мощи? Они были не слабыми, а, скорее, немощными.

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

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

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

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

Давайте изучим это на примере деградации кода.

Технический долг: не моя проблема

Мне не нравится концепция «технического долга».

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

Но предотвращает ли эта концепция принятие подобных кратковременных решений? Такого я не встречал никогда.

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

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

Однако чаще всего понятие технического долга возлагает бремя вины исключительно на разработчиков. Если бы только разработчики были лучше, если бы у нас были те самые 10x-разработчики, о которых мы часто слышим, если бы они работали упорнее, то мы бы могли полностью обойтись без проблемы технического долга.

Поэтому ничто не мешает руководству сказать: «Нам нужно, чтобы ты поторопился и пришёл поработать в субботу, ладно?» Отлично. Дело сделано!

Но нам нужен какой-то другой термин. Нечто такое, что могло бы пробрать менеджеров в пиджаках.

То есть деградация кода.

Настоящую деградацию кода невозможно «замести под ковёр»; она становится результатом плохо организованного процесса. Это непосредственный результат плохого руководства, и устранить его могут только организационные изменения.

Вот, как это работает:

Деградация кода, шаг 1: реальные решения принимаются реальными игроками

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

Этот процесс затрагивает эго многих сторон. Чем больше у вас веса во влиянии на роадмэп, тем больше денег вы контролируете и тем власти имеете.

И вы сохраняете за собой место в конференц-зале благодаря тому, завершаете проекты вовремя и с соблюдением бюджета. Должны ли эти завершённые проекты хорошо работать? Теоретически, да. На практике, своевременное завершение — это достаточно близкий косвенный показатель успеха; остальное можно исправить при помощи антикризисных мер.

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

Деградация кода, шаг 2: на сцене появляется программное руководство

Поэтому когда ситуация неизбежно усложняется, высшее руководство удваивает давление.

Самый распространённый способ реализации проектов из роадмэпа во время и в рамках бюджета — создание команды, имеющей особые полномочия: программного руководства. Эта группа «удлиняет» финансовый рычаг компании, поэтому отчитывается непосредственно перед высшим руководством.

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

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

Последнее, что бы они хотели услышать, так это то, что вашей команде нужно перенести проект, чтобы подчистить «технический долг».

Деградация кода, шаг 3: план проекта против реальности

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

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

Однако проекты по разработке ПО похожи на прыжок с самолёта; невозможно понять, что это такое, пока ты на самом деле этого не сделаешь.

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


Когда работу разбивают на проекты, возникает множество серых областей

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

Деградация кода, шаг 4: серые области приводят к отсутствию ответственности

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

Так что же должна делать команда, постоянно находящаяся в условиях нехватки времени?

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

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

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

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

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

Деградация кода, шаг 5: плохой код размножается

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

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

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

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

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

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

С ростом системы серые области становятся всё больше по сравнению с работой над текущим проектом и рано или поздно начинают доминировать в кодовой базе.

Потенциал сбоев из-за небрежности поистине безграничен. Как сказал Толстой, «все качественные кодовые базы похожи друг на друга, каждая связанная кодовая база связана по-своему».

Деградация кода, эндшпиль: коллапс

Сад, за которым не ухаживают, зарастает сорняками.

Можно нанять лучших разработчиков, привлечь agile-коучей, даже заставить всех работать по субботам, но кодовая база без реального владения со временем деградирует. И так будет каждый раз.

А в больших масштабах деградация приводит к коллапсу.

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

Высшее руководство может быть раздосадовано некомпетентностью своих инженеров, но что те могут поделать?

Посмотреть в зеркало? Вряд ли.

Нет. Мы скажем, что на этот раз всё будет иначе. Мы скажем, что все сделали выводы.

И если вам повезёт работать над новой версией, то до возвращения деградации кода у вас будет несколько лет.

Но вы ведь к тому времени наверняка уволитесь, так ведь?

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