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

Я тоже нет. Более того:

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

Исследование Stripe ^[1]

Только вдумайтесь. Это 85 миллиардов долларов.

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

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

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

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

Макротренды, делающие технический долг неизбежным

Первый закон термодинамики

Также известен как закон сохранения энергии ^[2]; утверждает, что:

Полная энергия замкнутой системы остается постоянной; говорят, что она сохраняется с течением времени.

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

Если без лишних сложностей, давайте думать о нашей кодовой базе как о замкнутой системе ^[3]. Отбросим внешние зависимости и всё, что живет за пределами нашей кодовой базы. В этих условиях — неизменное количество разработчиков, разработка фич в стабильно высоком темпе — количество энтропии (мера беспорядка и случайности в системе ^[4]) в нашей кодовой базе остается постоянной.

Наши разработчики не могут стать сверхлюдьми за одну ночь, поэтому мы не можем увеличить их эффективность, если они уже и без того выкладываются на максимум. Но мы можем нанять больше разработчиков, а это увеличивает энергию в нашей системе. Вот почему верен закон Брукса ^[4]: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше» — потому что это увеличивает энергию, или хаос, в системе, где хаос и без того уже велик.

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

Но постойте. Почему это ведёт к росту технического долга?

Второй закон термодинамики

Беспорядок в замкнутой системе не может уменьшаться; он может только оставаться неизменным или увеличиваться.

Фактически, замкнутые системы переходят в состояние большего беспорядка естественным образом. Этот «беспорядок» — который мы назвали выше «энергией» или «хаосом» — называется энтропией. Ивар Якобсон ^[5] и его коллеги исследовали феномен энтропии в кодовых базах и ввели термин энтропия программного обеспечения ^[6]. По мере внесения изменений в кодовую базу её энтропия увеличивается. Этот ширящийся хаос является причиной технического долга.

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

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

Ron Pragides ^[7], вице-президент по разработке в Carta

Планируя каждый спринт, наша компания оказывается перед выбором: нужно ли сделать что-то для обуздания растущей сложности или стоит потратить время на разработку и доставку новых фич?

Третий и последний закон термодинамики проясняет, почему эта дилемма даже близко не отвечает истинному положению вещей.

Третий закон термодинамики

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

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

Итак, что мы можем сделать, чтобы управлять энтропией ПО?

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

Однако вечно держать код в замороженном виде невозможно — нам нужны новые фичи. Так что единственный вариант, который нам остаётся, — это рефакторить.

Процесс рефакторинга кода может способствовать поэтапному сокращению энтропии программного обеспечения.
Википедия ^[6]

Бесплатное расширение для VSCode, которое поможет вам в этом ^[8]. Начните сейчас, пока ситуация не вышла из-под контроля!

Уменьшить энтропию ПО не так уж просто

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

Почему же технический долг по-прежнему застает нас врасплох?

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

Все мы знаем закон Мура, однако подумайте и о варианте закона Вирта ^[9] в изложении Билла Гейтса:

Скорость программного обеспечения уменьшается наполовину каждые полтора года.
Билл Гейтс

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

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

Источник: The Emerging Future ^[10]

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

Кадры реальной видеосъемки команды разработчиков, сражающейся с техническим долгом

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

Автор: bevalorous

Источник ^[11]