Вы когда-нибудь слышали о команде разработки программного обеспечения, которой бы не приходилось сталкиваться с техническим долгом?
Я тоже нет. Более того:
Инженеры тратят около трети своего времени на технический долг, что снижает боевой дух команд и обходится компаниям примерно в 85 млрд. долларов ежегодно.
Исследование Stripe
Только вдумайтесь. Это 85 миллиардов долларов.
Треть всего времени разработчиков тратится на технический долг. Это наполняет разработчиков ужасом. Это, на самом деле, худшая часть их работы — и масла в огонь подливает то, что остальная часть бизнеса часто никак им не сопереживает. Здесь нет чьей-либо вины, но технический долг повсеместно недооценивается. Из-за него софтверные компании медленно закостеневают, до тех пока не утратят способность к росту, не требующему затрачивать месяцы и годы на переписывание своих приложений с нуля… а такие сроки на сегодняшнем рынке — это целая вечность.
Технический долг — явление заурядное, так ведь? Мы начинаем писать код, технический долг накапливается, и бум, его внезапно становится слишком много. Наша кодовая база оказывается погрязшей в нём, и мы приходим к техническому банкротству. Поэтому мы с ним боремся. Мы смиряемся с мучительной необходимостью и выплачиваем часть долга. Иногда у нас получается это делать, иногда нет. В этом суть разработки программного обеспечения. Так уж у нас всё устроено.
Но разве всё должно быть именно так? Есть ли какие-то фундаментальные законы разработки программного обеспечения, которые ответственны за это? И, если да, можем ли мы использовать эти законы себе во благо? Технический долг — обычное явление, но им не должно быть техническое банкротство.
Давайте обратимся к различным областям науки за некоторыми подсказками, потому что законы термодинамики могут подарить нам ключевые идеи для понимания того, почему технический долг неизбежен.
Макротренды, делающие технический долг неизбежным
Первый закон термодинамики
Также известен как закон сохранения энергии; утверждает, что:
Полная энергия замкнутой системы остается постоянной; говорят, что она сохраняется с течением времени.
Другими словами, энергия не может быть создана или уничтожена, однако она может переходить из одной формы в другую.
Если без лишних сложностей, давайте думать о нашей кодовой базе как о замкнутой системе. Отбросим внешние зависимости и всё, что живет за пределами нашей кодовой базы. В этих условиях — неизменное количество разработчиков, разработка фич в стабильно высоком темпе — количество энтропии (мера беспорядка и случайности в системе) в нашей кодовой базе остается постоянной.
Наши разработчики не могут стать сверхлюдьми за одну ночь, поэтому мы не можем увеличить их эффективность, если они уже и без того выкладываются на максимум. Но мы можем нанять больше разработчиков, а это увеличивает энергию в нашей системе. Вот почему верен закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше» — потому что это увеличивает энергию, или хаос, в системе, где хаос и без того уже велик.
Быстрорастущие софтверные компании борются с этой силой постоянно. Они поднимают раунд инвестиций, удваивают объем команды разработчиков так быстро, как им позволяет рынок труда, а затем им приходится бороться с большим скачком «энергии» в своей кодовой базе. Это часто превосходит возможности компании и может привести к резкому росту технического долга, если не принять срочных контрмер.
Но постойте. Почему это ведёт к росту технического долга?
Второй закон термодинамики
Беспорядок в замкнутой системе не может уменьшаться; он может только оставаться неизменным или увеличиваться.
Фактически, замкнутые системы переходят в состояние большего беспорядка естественным образом. Этот «беспорядок» — который мы назвали выше «энергией» или «хаосом» — называется энтропией. Ивар Якобсон и его коллеги исследовали феномен энтропии в кодовых базах и ввели термин энтропия программного обеспечения. По мере внесения изменений в кодовую базу её энтропия увеличивается. Этот ширящийся хаос является причиной технического долга.
Вернёмся к нашей быстрорастущей софтверной компании, чья клиентская база продолжает расширяться, а рынок растёт. Их увеличивающаяся команда разработчиков день и ночь выкатывает фичи, чтобы успеть за ростом. Если ничего не делать, кодовая база станет только запутаннее. Давление нарастает.
Я рассматриваю технический долг как энтропию в кодовой базе. Я не думаю, что он когда-нибудь исчезнет, борьба с ним будет постоянной.
Ron Pragides, вице-президент по разработке в Carta
Планируя каждый спринт, наша компания оказывается перед выбором: нужно ли сделать что-то для обуздания растущей сложности или стоит потратить время на разработку и доставку новых фич?
Третий и последний закон термодинамики проясняет, почему эта дилемма даже близко не отвечает истинному положению вещей.
Третий закон термодинамики
Энтропия системы достигает постоянного значения, когда температура равна абсолютному нулю.
Звучит сложно, но в действительности, довольно просто по сути, и хотя законы термодинамики имеют далеко идущие (и иногда просто ошеломляющие) последствия, их основы легко понять. Например, когда вода принимает форму пара, ее молекулы «свободны» двигаться совершенно хаотичным образом. Энтропия повсюду. Однако, когда вода замерзает, её молекулы оказываются «заперты» и остаются на месте (более или менее). Энтропия уменьшается и достигает постоянного значения.
Итак, что мы можем сделать, чтобы управлять энтропией ПО?
Ну, мы могли бы остановить разработку нового кода. По этой причине некоторым командам нравится «заморозить» код, чтобы хорошенько протестировать свою систему перед релизом для клиентов. Если кодовая база больше не изменяется, то энтропия не растет, хаос тоже, нет больше непредвиденных последствий, и технический долг не увеличивается.
Однако вечно держать код в замороженном виде невозможно — нам нужны новые фичи. Так что единственный вариант, который нам остаётся, — это рефакторить.
Процесс рефакторинга кода может способствовать поэтапному сокращению энтропии программного обеспечения.
Википедия
Бесплатное расширение для VSCode, которое поможет вам в этом. Начните сейчас, пока ситуация не вышла из-под контроля!
Уменьшить энтропию ПО не так уж просто
Пока всё неплохо. На самом деле, всё это выглядит как констатация очевидного; любой, кто что-нибудь слышал о разработке ПО, знаком со всем этим, по крайней мере интуитивно.
Почему же технический долг по-прежнему застает нас врасплох?
Это потому, что даже при том, что мы знаем о необходимости рефакторить код для снижения запутанности, существует еще мириад других довлеющих над нами сил, которые не дают нам выделять время и ресурсы, необходимые, чтобы делать рефакторинг правильно и достаточно часто. Это означает, что и в нашей, и во всех прочих кодовых базах энтропия ПО постоянно растёт.
Все мы знаем закон Мура, однако подумайте и о варианте закона Вирта в изложении Билла Гейтса:
Скорость программного обеспечения уменьшается наполовину каждые полтора года.
Билл Гейтс
Я убежден, что растущая энтропия наших кодовых баз — главная движущая сила этой закономерности.
Темп роста энтропии ПО напрямую связан с темпами роста таких факторов, как технологии, рынки ПО, софтверные компании и грамотность написания кода — и каждый из них растёт чертовски быстро.
Источник: The Emerging Future
Вообразите давление, которое эти ожидания оказывают на команды разработки программных продуктов. Это серьёзные общемировые тренды, и относительно небольшой группой людей они могут ощущаться как сокрушительные. Это почти как просить их побороть гравитацию и взлететь, размахивая руками.
Кадры реальной видеосъемки команды разработчиков, сражающейся с техническим долгом
В следующей статье мы рассмотрим микротренды, постоянно подталкивающие нас к техническому банкротству, а также то, как быстрорастущие софтверные компании могут с ними побороться. Оставайтесь с нами!
Комментарии (24)
Indemsys
21.12.2019 00:50+1Технический долг — метафора. А статья предлагает метафоры к метафоре.
Кто нибудь объяснит о чем все таки речь?
Если это действительно долг, то почему его не взыскивают через суд?
Если это просто не идеальный код, то где доказательства что идеальный код существует?
Словом как количественно оценить этот долг если он объективно существует как явление, а не как субъективное ощущение?
szelga
21.12.2019 07:24Если это действительно долг, то почему его не взыскивают через суд?
зачем обязательно через суд? его и так жизнь взыскивает. с пенями.Indemsys
21.12.2019 11:36Ну тогда что такое идеальная жизнь, и когда она взыскивает, а когда бьет ни за что?
Не стоит ли говорить просто о фитбэке (обратной свзи) и подойти к проблеме с точки зрения теории управления и фильтрации и не мистического долга перед жизнью.
bevalorous Автор
21.12.2019 12:11+1Гляньте то расширение, которое разработали авторы этой статьи. Там описаны вполне измеримые количественные критерии запутанного и сложного в сопровождении кода:
- длина функций
- цикломатическая сложность
- метрика сложности Холстэда
- количество аргументов функций
- глубина вложенности
- насыщенность кода комментариями
Полюбопытствуйтеmvv-rus
21.12.2019 22:51+1Ну, полюбопытствовал. Всё перечисленное там — это не метрики технического долга, а метрики сложности кода. Технический долг же — это не вся, а лишь избыточная часть сложности кода.
Кроме избыточной сложности в программе есть ещё необходимая сложность, которая определяется сложностью самой задачи (и её предметной области), для решения которой и создана программа. И которую (сложность) невозможно определить a priori. Поэтому сама идея измерения технического долга сталкивается в реальности с неустранимой систематической ошибкой такого измерения.
Помимо этого, идея померить сложность несколькими метриками неизбежно приведет к тому, что начнет действовать закон Гудхарта: когда показатель становится целевым в политике управления, то эмпирическая закономерность, на основе которой можно этот показатель использовать для управлния, перестает выполняться.
В нашем случае, если менеджмент попытается контролировать подобным способом технический долг, наемные разработчики и их команды научатся, грубо говоря, обманывать систему оценки технического долга, прятать избыточную сложность кода способами, не контролируемыми по отслеживаемым менеджментом показателям — просто чтобы не портить себе формальную оценку от которой будет зависеть их доход. В частности, перечисленные в статье по ссылке показатели — они вполне подвержены такому обману.
Например, формально уменьшить число строк в функции вполне возможно за счет механического разбиения её на дочерние процедуры, с передачей общего (и изменяемого внутри дочерних процедур) состояния родительской функции между ними через передаваемые по ссылке параметры, глобальные переменные и т.д., чтобы не уменьшать реальную сложность программы. Число ветвей исполнения можно аналогичным образом уменьшить формально, перенеся их реализацию в дочерние процедуры, но принимая решения об используемых ветвях в родительской функции и передавая все принятые решения с помощью единственного параметра-набора флагов; число аргументов можно формально уменьшить, передавая вместо многих аргументов один содержащий их объект; требование о количестве комментариев можно формально соблюдать, комментируя очевидные вещи: я вряд ли когда-нибудь забуду забавный комментарий «Handy 1»(«удобная единица») к команде загрузки 1 в регистр процессора в написанном на ассемблере модуле IBM VM/SP — для которого фирменный стандарт, по-видимому, требовал комментировать каждый оператор.
И так далее: для каждой метрики «технического долга» найдется способ её формального соблюдения без фактического сокращения сложности — как писал Эд Пост в своей очень старой и хорошо известной статье «закоренелый настоящий программист может написать фортрановскую программу на любом языке».bevalorous Автор
22.12.2019 10:08Это статья из корпоративного блога компании, которая занимается разработкой решений для отслеживания и устранения технического долга в коде с помощью IDE. Так что, думаю, она обращена прежде всего не к менеджменту, а к разработчикам, то есть людям, работающим с кодом, небезразличным к своей работе, желающим ее улучшить. Про менеджмент там скорее посыл в том, что выплачивать технический долг так же важно, как и выкатывать новые фичи, и нельзя экономить на первом за счет второго — это может плохо кончиться. В остальном совершенно с вами согласен: если разработчикам наплевать на то, как они пишут код, как их работа влияет на других в команде и на фирму в целом, и единственная их цель — выполнить спущенные сверху формальные показатели, то да, никакие метрики, KPI и т.п. не заставят их делать свою работу хорошо — обойдут, обманут, подкрутят. Это уже не команда, слаженно работающая на достижение общей цели. Но это уже совсем другая проблема, и такая организация, на мой взгляд, глубоко больна и находится на пути к краху.
Indemsys
22.12.2019 12:27Ну все к тому и пришло.
«Технический долг» — эвфемизм фразы «вы виноваты».
Т.е. виноваты простыне кодеры, поскольку превысили цикломатичность и все такое.
Причем граница для всех критериев «долга» выбирается эмпирически, как пишут сами авторы этого набора критериев.
Хочешь усилить чувство вины молодых кодеров — опусти границу цикломатичности.
При этом избегается тема получения единой оценки долга, т.е. агрегирования оценок по всем критериям и получения единственного числа, а главное определение справедливой границы.
Отличный инструмент психологического давления.
SirEdvin
21.12.2019 11:12Если без лишних сложностей, давайте думать о нашей кодовой базе как о замкнутой системе. Отбросим внешние зависимости и всё, что живет за пределами нашей кодовой базы. В этих условиях — неизменное количество разработчиков, разработка фич в стабильно высоком темпе — количество энтропии (мера беспорядка и случайности в системе) в нашей кодовой базе остается постоянной.
Из неправильного предположения вытекает неправильное следствие — в итоге, так или иначе в техническом долге виноваты только разработчики, пусть это можно списать на сущность человеческой природы.
На практике, кодовая база это не закрытая система. Она катастрофически часто претерпает проблемы со стороны заказчика (аутсорс) или бизнеса (продуктовая разработка). И обычно все проблемы бизнеса в духе кривых бизнес-процессов или "сделай как-то так, там же все понятно" в первую очередь отображаются в ней, потому что плохо продуманные бизнес-процессы как-то людьми залепить можно, а с кодом так не сработает.
bevalorous Автор
21.12.2019 12:04Об этом в статье есть, и не один раз:
- общее убеждение бизнеса, что технический долг — проблема только команд разработчиков
- недооценивание всей серьезности технического долга и его влияния на возможности роста бизнеса
- постоянное давление со стороны рынка («делай быстро или конкуренты обгонят»)
- ложно понимаемая дилемма «новые фичи или рефакторинг», чаще всего решаемая в пользу первого варианта
Вы ведь статью прочитали полностью?SirEdvin
21.12.2019 12:09+1Об этом в статье есть, и не один раз:
Эти утверждения же не опровергают ложного вывода статьи в том, что "источник технического долга — разработчики". Разумеется, проблемы IT отдела (как и любого другого) в итоге будут проблемами бизнеса, но в том числе важно понимать, что очень часто именно бизнес-решения порождают технический долг, а не "неидеальность" разработчиков.
Я могу переформулировать это как "очень часто технический долг не возникает сам по себе, а бизнес намеренно увеличивает технический долг зная или игнорируя риски с ним связанные, дабы получить выгоду для себя".
bevalorous Автор
21.12.2019 12:20Непосредственный источник технического долга в кодовой базе — это именно разработчики, потому что именно они работают с кодом и вносят в него изменения, так что вывод отнюдь не ложный. Именно разработчик решает реализовать бизнес-требования через костыль, и именно он вносит этот костыль в код и берет тем самым на себя ответственность и за этот костыль, и за его будущую судьбу, и за рост долга, и за его влияние на всех прочих в команде, и даже за влияние этого костыля на бизнес в целом. Удобно все свалить на злых менеджеров, но ведь и менеджеры со своей стороны не всегда понимают, что делают разработчики, к каким последствиям это может привести, и главное — в конечном счете это не они пишут код с костылями.
fzn7
21.12.2019 12:41Ответственность возникает при наличии права свободы выбора. В случае прямой директивы от бизнеса никакой ответственности на разработчике нет
SirEdvin
21.12.2019 15:06Именно разработчик решает реализовать бизнес-требования через костыль, и именно он вносит этот костыль в код и берет тем самым на себя ответственность и за этот костыль
У вас сроки реализации тоже разработчик сам себе ставит? Я обычно видел ситуации, когда есть срок, к которому нужно реализовать фичи, к которому ее реализовать нормально нельзя и происходит стандартный диалог на тему "ну мы же потом перепишем — конечно", а потом чуда не происходит.
А еще это мы не затрагивает ситуацию, когда какой-то топ-менеджер по 6 раз кардинально меняет требования к задаче в течении времени ее реализации. И каждый раз давит на разработчиков с тем, что бы ее реализовали быстрее. В итоге код будет просто отвратительный и тоже разработчики будут виноваты?
qw1
21.12.2019 15:40+1Странный разработчики, если поддаются на давление.
Я, например, никогда не буду писать код, который мне совсем уж не нравится (например, без проверки ошибок или без должной декомпозиции).
Я могу оставить костыль, только если мне будет лень писать правильно, например, я уже устал от какой-то задачи и сам хочу быстрее её завершить. Но это моё решение, а не какого-то менеджера.
Не представляю, чем они могут оказывать давление. Если репутационно, типа «смотри, Вася фигачит в 3 раза быстрее» — то я спокойно отвечу «ну и фигня у него получается, так что пофиг», если же через премии, то я посчитаю это несправедливым и скажу такому работодателю «давай, до свидания», хотя таких прецедентов не было. Благо, сейчас рынок на стороне работника.
bevalorous Автор
21.12.2019 16:03Неадекватность менеджмента, не встречающая отпора от исполнителей. Типичная ситуация, хорошо знакомая всем, наболевшая. Проиграют в итоге и те, и другие.
Vlad_fox
23.12.2019 13:34Давайте обратимся к различным областям науки за некоторыми подсказками, потому что законы термодинамики могут подарить нам ключевые идеи для понимания того, почему технический долг неизбежен.
давайте, но только к тем, которые изучают открытые развивающиеся системы с обратной связью
gleb_l
Энтропийная модель проектных команд с привлечением законов термодинамики — это хорошо, но по сравнению с материей у человеков есть одно ключевое отличие: разум, подобно тепловому насосу, способен понижать энтропию в конечной области Вселенной, естественно, за счет увеличения за ее пределами.
Поскольку нас прежде всего интересует энтропия кодовой базы, то бабка говорит надвое — добавление новых людей в команду может как ее увеличить, так и уменьшить. Все зависит от вышеуказанной способности этих людей вносить упорядочивающую составляющую в процесс разработки.
К командной работе можно привести и электротехническую аналогию — как повлияет на отдаваемую батареей элементов мощность добавление к батарее еще одного элемента? Ответ в реальности троякий, и зависит от внутреннего сопротивления добавляемого элемента, его ЭДС и сопротивления нагрузки. Так и в команде.
dzsysop
Конечно вы правы, если пытаться рассмотреть какую-то конкретную команду разработки и конкретный проект.
Но я полностью согласен с автором, что если мы берем среднего разработчика и команда у нас состоит из средних или скажем одинаково хороших разработчиков и мы добавляем туда еще одного такого же условно хорошего разработчика, то не стоит ожидать что система начнет меняться и энтропия начнет исчезать. Она таки начнет возрастать. В этом смысле, если говорить про чистую разработку в отрыве от других подразделений, то таки сократив число разработчиков можно в среднем добиться падения роста энтропии.
ЗЫ: В этом смысле, мода на микросервисы, это именно о том, чтобы в кодовой базе чего-то определенного копалось меньше разработчиков. Таким образом мы достигаем снижения энтропии разбив монолит и раздробив большую команду на более мелкие.
gleb_l
Комплектация проектных команд — не гауссовый процесс — она является результатом добавления в систему информации (осознанного решения [толкового] менеджера)
Ваш же пример со средним разрабом будет справедлив в случае, если количество информации, привносимой в команду менеджером, строго равно нулю.
Положим, что в большинстве проектных команд это все-таки не так. Следовательно, если цель — уменьшение энтропии, то добавляемый в батарею элемент будет более качественным (то есть иметь лучшее отношение E/ri) — иными словами, разраб будет более квалифицированным и дорогим, чем средняя смесь в команде.
Обратная задача — удешевить выход проекта за счет допустимого роста технического долга в самом конце (и удорожания пост-продакшен поддержки в будущем [но об этом думать будет уже менеджер команды сопровождения]) — решается добавлением в смесь менее качественных и более дешевых разрабов
gleb_l
Модель потерь в микросервис-архитертуре — это переходные сопротивления и помехи на контактах множества межблочных соединений. Самы блочки при этом выглядят опрятно и аккуратно. Залиты лаком — не грех заказчику показать, или на выставке похвастаться.
В полевых же условиях очень многое зависит от уровня деления и качества разъемов. Чтобы микросервисы при интенсивной замене блоков продолжали надежно работать — разъемы должны быть с военной приемкой, и сплошь золоченые.
Вы понимаете аналогию — стоимость поддержки когерентности межсервисных соглашений при их большом количестве и интенсивной модернизации сервисов растет квадратично!
Так что для сложных систем и/или динамичных стартапов опять приходит бабка и говорит надвое, кашляя и ругаясь на очередной технологический хайп
dzsysop
Понимаю и мне аналогия кажется очень уместной и наглядной.
Именно поэтому переход на микросервисы далеко не всегда являются улучшением. Но в то же время если говорить про энтропию, энтропия кодовой базы таки должна снижаться. просто она повысится теперь где-то в другом месте, на стыке микросервисов :-)
gleb_l
Да, в определенном смысле, в этом даже есть резон — в отличие от блоков, структура которых сложная и многообразная, соединения — просты и подобны. Это значит, что метод поддержания низкой энтропии всех соединений системы может быть по сути один, и за счет этого можно достичь определенного снижения функции затрат при фиксированной функциональной сложности и общей энтропии системы.
Есть, правда, еще один класс проблем мультисервисов — конечная скорость распространения межмодульной информации — здесь полная аналогия с понятием «длинная линия» в электронике, вследствие чего когерентные межмодульные операции становятся либо очень сложны, либо невозможны. И это — тоже вытеснение сложности в другое измерение (в данном случае — из технической в бизнес-плоскость).
Короче, все эти усилия — суть домкраты, трансформаторы, полиспасты и тому подобные приборы с конечным КПД — результат преобразований энергии в информацию о том, как обыграть Природу в том или ином частном случае :)
bevalorous Автор
В одной из книг о микросервисах была целая глава о том, когда не нужно их применять. Одним из пунктов было неумение/незнание/непонимание компанией технологий контейнеризации и оркестрации: без них работа с микросервисами быстро превратится в ад.
bevalorous Автор
Интересная аналогия. В принципе, многие приемы управления разработкой в команде при должном применении делают замену или добавление новых разработчиков таким же простым и предсказуемым процессом, как добавление нового элемента к батарее.