Технический долг: что и кому я должен? Сага | АйТи-Капитан Объясняет

Всем привет. Я Михаил, канал IT Капитан. Сегодня 

хочу поговорить про технический долг. Технический долг программной инженерии - это накопившиеся 

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

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

Мне неинтересно просто дать вам определение. Мне гораздо интересней не чтобы вы узнали, 

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

сталкиваются, э, и посмотреть на всё это в разрезе процессов в IT-отделе, в отделе разработки 

программного обеспечения. Итак, как обычно, начнём с демонстрации кусочка нашего конвейера 

по разработке программного обеспечения. Давайте рассмотрим всё на примере компании, продукт, 

который - это конструктор интернет-магазинов. Вот мы, допустим, эта компания. Сразу скажу, все 

совпадения случайны. Значит, у нас есть вот отдел разработки, разработчики, frontнend разработчики. 

Они выполняют какую-то задачу, укладывают свой код на тестовый сервер, тестировщики проверяют. 

выкатывают в продакшн и пользователи начинают использовать новую функциональность. Также мы 

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

интернет-магазине. И приложено техническое задание. Давайте заглянем в него. Такая 

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

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

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

заказа и процентная скидка. То есть раньше её не было. Добавляем в настройку такой пункт. 

Добавляем поле для ввода размера этой скидки. Ну, всё остальное остаётся, как и было ранее. Итак, 

задача пришла в отдел разработки. По фронту там мало пару полей добавить. В основном работа на 

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

отвечает за логику на этой странице Checkout, и маленько ужаснулись. Вроде бы небольшой участок 

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

нарисовать корзину, попробовать посчитать, скалькулировать, и всё у нас получится очень 

складно с этим самым применением промокода. Но в коде мы видим 1.000 строк так 

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

много дублирований, и он никак не соответствует ни вообще никаким критериям 

качества. То есть первая версия этого чекаута была написана 10 лет назад и потом поддерживалась 

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

время старались вообще не трогать, потому что нельзя внести в него изменения с 

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

предлагает prodctт-менеджерам, например, произвести рефакторинг. Что такое рефакторинг? 

Он предлагает чуть-чуть переписать чекаут, но в нашем случае не чуть-чуть, а, например, 

полностью. Полностью его переделать. Продакт-менеджеры не очень-то горят желанием, 

и их можно понять. В продуктовой разработки один из главных показателей - это time to 

market. Зачем нам сейчас что-то переписывать, сидеть? Пользователи всё равно, давайте лучше 

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

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

О'кей. Кэнтер. Заработчики соглашаются. Итак, задача сделана. Загружен на 

тестовый сервер. Тестировщики проверили, выгрузили в прот. Пользователи пользуются. 

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

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

передаёт тикет в отдел тестирования, чтобы те подтвердили или опровергнули наличие 

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

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

коммуникации, которые, в принципе, не хотелось бы, чтобы у нас были, но они произошли из-за бага. 

Значит, нам поступает в отдел разработки, вот backнд разработчикам, frontндразработчикам, 

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

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

Хорошо, возможно, что-то сломали, давайте это поправим. на что разработчики резонно замечают, 

что лучше бы, конечно, порефакторить этот раздел, но прожект-менеджеры остаются при 

своём мнении: "Давайте попробуем сначала так, вдруг получится поправить, и всё, не 

придётся ничего переписывать". О'кей. Итак, на четвёртую неделю нашей саги бкэнд 

разработчики по предприняли попытку исправить бак. Запустили, проходит ещё пару недель, и 

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

поддержки. Отдел тестирования подтверждает наличие бага. От менеджмента приходит 

вопрос, что у нас вообще происходит? Почему ничего не получается? Какая-то вроде бы 

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

А у нас столько проблем и столько жалоб. Кэнд разработчики по-прежнему предлагают 

рефакторинг, потому что, да, участок кода проблемный, да, были предположения, что именно 

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

данных у нас и маловато. Поэтому давайте мы с вами обратимся к нашей службе поддержки и к службе 

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

за, может быть, какие-то более ранные периоды. Что у нас вообще? Часто ли какие-то проблемы 

возникают по чекауту? Может быть, действительно там всё плохо. Мы даём бэкнтрозаработчикам новую 

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

процессе оформления заказа, и, может быть, как-то классифицируйте их. Кэнд разработчики 

прибегают к помощи тестировщиков и начинают разбираться, что вообще происходит, как часто и 

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

аргументацией. Баги условно поделились на две категории: блокирующую покупку и неблокирующую. 

не блокирующие остаются незамеченными чаще всего, но чуть-чуть суммы где-то не сходится. То есть 

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

правим в одном месте, у нас ломается в другом. И вот эта сумма начинает чуть-чуть отличаться 

от желаемой. Но покупка всё равно совершается. Пользователи чаще всего просто не замечают. 

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

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

Просто никто не ругается особо. Ну было и было. Покупатель всё равно, например, совершил покупку 

или покупатель всё равно ушёл и всё, проблема становится неактуальным. Какой-то разовый случай, 

плавающие непонятные проблемы. Ну вот так. Вторая категория проблем - это баги, блокирующие покупку. 

То есть пользователь не может совершить оплату. И выяснилась закономерность. Во всех случаях была 

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

была подключена отправка чеков онлайн-кассы. И здесь мы начинаем догадываться, что расчёты 

ведутся неправильно совсем. Значит, вот на какую сумму у нас товаров. Применили скидку 17% 

умножением на 0,83. Получили число такое же, как вот у нас здесь на проекте. Ну давайте попробуем 

посчитать по-другому. Попробуем применить скидку не ко всем товарам сразу, а к каждой единице 

товара и посмотреть, что у нас получится. Расчёт начинает выглядеть вот так. Каждый стоимость 

умножаем на 0,83, а потом уже на количество. Вот такой расчёт получается. Итоговая сумма та же 

самая. Но вот здесь интересный момент. Смотрите, дробная часть от рублей, три цифры, 455. У нас 

минимальная единица валюты - это копейка. То есть здесь может быть, э, 45 коп. Да, это нормально, 

но 45,5 копек невозможно. И интернет банки наши, интернеткваринги, у некоторых банков, которые 

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

суммы перестают сходиться. Мы должны производить расчёты по-другому. Давайте прямо вот напишем. Вот 

здесь у нас не может быть стоимость одного товара с дробной копейкой. Мы должны округлить в большую 

сторону. И тогда у нас получится вот такая сумма, не 91 коп., а 92 коп. И это правильно. И 

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

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

жалуются, они просто уходят и покупают в другом магазине. Поэтому проблема тоже не всегда 

заметна. Здесь ситуация уже довольно плачевна. Вот этими расчётами, вот вот этими вот этими 

вот расчётами прониза пронизана вся наша функция чекаута, которая вот эта вот страшная там на 

1.000 строк. И просто так взять и переписать на вот такой способ применения скидки не получится. 

Здесь уже точно гораздо проще просто переписать всю эту функциональность. с нуля. Кэнтер. 

Заработчики повторяют свой вопрос. Ну а что нам остаётся делать? Мы соглашаемся. Количество 

жалоб от пользователей растёт. Разработка зашла в тупик. Правишь одно место ломается в 

другом. Расчёт скидки сделан неправильно. Вообще полностью нужно переписывать. Поэтому 

да. О'кей. Мы даём своё добро. Одна из самых частых причин накопления технического долга - 

это давление бизнеса. на примере убедились в том, что да, это может происходить и увидели, как это 

может происходить, зачем нам что-то переписывать, какую-то функциональность, которую мы уже 

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

добавим и всё. Но нет, как бы это нехорошо и неплохо, что так происходит. Это просто 

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

или сколько-то разработчиков просто влетают из разработки, пропадают там на 2-че недели для того, 

чтобы что-то переписать. Это может быть критично в какой-то момент. Поэтому здесь единственная 

рекомендация может быть - это уделять время гигиене кода. 40 часов в неделю из них от четырёх 

до 8ми выделять на возмещение технического долга, причёсывать что-то улучшать, выделять новые слои 

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

отдельное видео, тоже очень интересная тема. Хочется о ней поговорить и рассказать 

много интересного. Подписывайтесь. До скорого.