технологический долг что такое
Технический долг
Программные системы склонны к накоплению мусора — внутренних недоработок, которые затрудняют дальнейшее изменение и расширение системы по сравнению с идеальным кодом. Технический долг — это метафора, придуманная Уордом Каннингемом. Она объясняет, как воспринимать этот мусор, по аналогии с финансовым кредитом. Дополнительные усилия, необходимые для добавления новых функций, — это проценты по кредиту.
Представьте, что в моей кодовой базе есть модуль путаной структуры. Нужно добавить новую функцию. Если бы структура была ясной, то работа заняла бы четыре дня, но с этим мусором требуется шесть дней. Разница в два дня — это и есть проценты по долгу.
Что меня больше всего привлекает в метафоре долга, так это ясное понимание расходов на его обслуживание или устранение. Я могу потратить пять дней на очистку модульной структуры, устранение мусора, метафорически расплатившись с «кредитором». Если я это сделаю для данной функции, то окажусь в проигрыше, потому что потрачу девять дней вместо шести. Но если появятся ещё две такие функции, то выгоднее всё-таки удалить мусор.
С такой формулировкой задача становится чисто математической. Её решит любой менеджер с электронной табличкой. К сожалению, мы не можем измерить производительность, поэтому никакие затраты объективно не измеримы. Мы можем примерно прикинуть, сколько времени требуется для разработки функции, сколько займёт работа после удаления мусора — и предположить стоимость его удаления. Но точность таких оценок довольно низкая.
Поэтому обычно лучший вариант — поступать так, как мы обычно поступаем с финансовыми долгами: постепенно выплачивать основную сумму. На первой функции я потрачу дополнительные пару дней, чтобы удалить часть мусора. Этого может быть достаточно, чтобы снизить проценты по долгу, так что в будущем его можно будет погасить за один день. Это по-прежнему дополнительное время, но после удаления мусора будущие изменения стали дешевле. Большое преимущество постепенного улучшения заключается в том, что естественным образом мы больше времени тратим на удаление мусора в часто изменяемых областях. Это именно те области кодовой базы, которые наиболее нуждаются в удалении мусора.
Сравнение выплаты процентов с выплатой основного долга помогает определить, с каким мусором разбираться. Если у меня есть какая-то особо ужасная область кодовой базы, то проблема исчезает, если выясняется, что мусор невыгодно удалять. Проценты выплачиваются только тогда, когда приходится работать с этой частью программного обеспечения (в этом месте метафора немного хромает, потому что по банковскому кредиту нужно платить всегда). Таким образом, кошмарные, но стабильные области кода можно оставить в покое.
В отличие от стабильных частей кода, области высокой активности требуют нулевой терпимости к мусору, потому что там процентные платежи чрезвычайно высоки. Это особенно важно, поскольку мусор накапливается там, где разработчики делают изменения, не обращая внимания на качество: чем больше изменений, тем больше риск появления мусора.
Метафора долга иногда используется для оправдания низкого качества кода. Аргумент состоит в том, что качественный код требует больше времени и усилий. Если срочно нужны новые функции, лучше принять на себя долг и разбираться с ним потом
Опасность здесь в том, что зачастую этот анализ ошибочен. Мусор очень быстро начинает вредить, замедляя внедрение новых функций. В итоге разработчики превышают кредитные лимиты и выпускают продукт позже, чем если бы сразу потратили время на обеспечение более высокого качества. Здесь метафора часто вводит людей в заблуждение, поскольку динамика технического долга на самом деле не соответствует динамике финансовых кредитов. Принятие на себя долга для ускорения выпуска продукта работает только в том случае, если вы остаётесь ниже линии design payoff в гипотезе об устойчивости архитектуры, а разработчики пересекают её уже через несколько недель, а не месяцев.
Регулярно ведутся дебаты о том, следует ли считать долгом различные виды мусора. Мне кажется, тут полезно учитывать, берётся долг сознательно и разумно — или безрассудно. Так появился квадрат технического долга.
Дальнейшее чтение
Насколько я могу судить, Уорд впервые представил эту концепцию в отчёте для OOPSLA 1992. Она также обсуждалось в вики.
Есть видеозапись, где Уорд Каннингем обсуждает придуманную им метафору.
Дэйв Николетт расширяет взгляд Уорда на технический долг, приводя прекрасный пример того, что я называю разумным преднамеренным долгом.
Несколько читателей предложили другие годные метафоры. Дэвид Панарити назвал некачественную разработку дефицитом программирования. Судя по всему, он начал использовать этот термин несколько лет назад, когда он соответствовал политике правительства; полагаю, теперь это снова актуально.
Скотт Вуд предложил рассматривать «техническую инфляцию как потерю почвы, когда текущий уровень технологии настолько превосходит уровень вашего продукта, что он постепенно выпадает из окружения. Программы отстают в версиях языка до такой степени, что код больше не совместим с основными компиляторами».
Стив Макконнелл выделил в метафоре несколько хороших моментов. В частности, как уменьшение непреднамеренного долга оставляет больше возможностей намеренно принять долг, когда это полезно. Мне также нравится его формулировка минимальных платежей (которые слишком высоки, чтобы исправить проблемы во встраиваемых системах, но не на сайтах).
Хенрик Книберг утверждает, что наибольшую проблему вызывает старый технический долг, и что разумно установить качественный потолок долга, чтобы им легче было управлять.
Эрик Дитрих обсуждает человеческие потери из-за технического долга: сражения в командах, деградация навыков и выгорание.
Технический долг: что это такое и как с ним жить
Быть или не быть регулярному рефакторингу? Мы попытались разобраться с этой холиварной темой — не без помощи людей, которые знают врага в лицо.
Технический долг — это модули, написанные на старых фреймворках, «костыли», мелкие недоработки, нарушенные стандарты и прочий мусор в коде, который в будущем усложняет жизнь. То самое чувство, когда читаешь код и думаешь: «Ну что за нехороший человек это всё писал». А потом оказывается, что этот «редиска» — ты сам из прошлого. Сам термин — метафора пионера паттернов и изобретателя технологии Wiki Уорда Каннингема.
Недоработки постоянно накапливаются. Чем их больше, тем сложнее добавить в код новую классную функцию. Необходимые усилия, которые придётся приложить в будущем, — как проценты по кредиту. Расплаты всё равно не избежать, а долг со временем всё растёт и растёт.
Согласно исследованию Stripe, разработчики тратят на технический долг треть своего времени, а компании «сливают» на это примерно 85 млрд долларов ежегодно. Быстро вывести на рынок жизнеспособный продукт, приносящий пользу бизнесу, — неплохое решение. Но надо помнить, что технический долг рано или поздно начнёт вредить проекту.
«Нельзя прийти и создать сразу идеальный проект. Каждый день мы будем что-то узнавать о предметной области, и эти новые знания нужно сразу внедрять. Вначале это будут костыли, из которых копится технический долг, — и это нормально. Ведь мы не можем, получая новую информацию, каждый раз переписывать продукт заново. Бизнес нас не поймёт».
Алексей Некрасов,
лидер направления Python в МТС, программный директор направления Python в Skillbox
Пишет про технологии и бизнес.
Технический долг в жизни: два примера
Если вовремя не подумать о техническом долге, приложение может подхватить хроническую болезнь: многочисленные уступки «надо прямо сейчас» так въедаются в код, что рефакторинг провести просто невозможно. Вот две истории — одна об успешной оплате долга, вторая — о запущенной «болезни», справиться с которой так и не получилось.
Локализация приложения
Канадская компания разработала хороший продукт для местных клиентов и решила повторить успех, расширив рынок сбыта на ту часть страны, где говорят в основном по-французски. Разработчики управились за неделю, добавив кучу if-then-else. Решение с оператором условий было быстрым и грязным, но на тот момент — оправданным. Продукт смог заработать ещё денег.
Месяц спустя в Японии фаундер похвастался, что поддержку японского они могут добавить за неделю. Но одно дело — по-быстрому накодить один дополнительный язык, и совсем другое — добавлять так же криво все последующие. Тем более что для японского решение с новым слоем if-then-else вообще не подходило — мешали иероглифы, да и текст японцы пишут вертикально. В итоге разработчикам пришлось писать нормальную систему локализации.
Бесконечные «если» и неудавшийся рефакторинг
Разработчики написали приложение на устаревших версиях Python, PHP и Java с жёсткой структурой из бесконечных операторов if. В какой-то момент они решили полностью переписать ядро на свежих версиях языков, но на каждом шагу объёмы работы возрастали — постоянно обнаруживались какие-то новые зависимости. Да и бизнес не хотел ждать — требовал новые функции, чтобы оставаться конкурентоспособным. В итоге за год рефакторинга команда практически не продвинулась вперёд.
Как оценить технический долг
Американский программист, автор книг и статей по архитектуре ПО Мартин Фаулер определял размер техдолга простой формулой: чем больше усилий программистов тратится на какой-то недоработанный в прошлом фрагмент кода, тем больше наш технический долг. При этом консультант по разработке ПО Роберт Мартин считает, что технический долг в прототипах и краткосрочных проектах можно и нужно игнорировать.
Есть разные классификации технического долга.
Например, CTO производителя весов для угарного газа Tapad Даг Лиодден выделяет три его типа:
Как правило, самый неприятный техдолг связан с архитектурными проблемами: отсутствием инкапсуляции и модульности, плохим применением шаблонов, несоответствием типов данных модели данных. Из-за этого тормозится разработка, трудно вносить изменения в код, исправлять ошибки. Такой долг трудно или вообще невозможно обнаружить инструментами вроде IDE, PMD или Checkstyle.
Чтобы понять, как победить техдолг, нужно тщательно его проанализировать.
Как объяснить бизнесу, что рефакторинг необходим
Владельцам софта нужна прибыль, поэтому они не хотят затягивать процесс разработки и бороться с техдолгом — особенно если близок старт продаж. Однако долг всегда приходится возвращать — иначе он создаёт проблемы в будущем продукте.
Конфликт разработчиков и бизнеса из-за рефакторинга — один из самых запутанных и сложных. Если игнорировать и копить техдолг, то разработчики потеряют мотивацию, а компания станет «техническим банкротом». Если же включить режим перфекциониста и слишком сильно фокусироваться на долге, конкуренты получат преимущество в скорости, быстрее выпустят новые фичи и захватят рынок. А полученную в ходе экспансии прибыль они вложат в погашение критичного долга — и останутся в выигрыше.
Вообще, Уорд Каннингем придумал концепцию техдолга именно для того, чтобы в понятных для бизнеса терминах аргументировать необходимость рефакторинга. Метафора простая: первая версия программы — как заём в банке. А каждая минута, которая тратится на исправление «костылей» в коде, — как проценты по кредиту. Если проценты долго не гасить, банк истребует весь долг и компания может закрыться. Однако небольшой долг, как и разумно взятый кредит, ускоряет разработку и помогает расти, главное — выплачивать его вовремя.
«Представьте платформу для нескольких независимых друг от друга клиентов ( из терминологии «клиент — сервер». — Прим. ред.). У каждого есть собственный сервис, весьма требовательный к аппаратным ресурсам. Пока клиентов мало, эта схема работает. Когда же количество клиентов резко увеличивается, возникает необходимость менять архитектуру и запускать один сервис, который будет обслуживать всех, вместо нескольких копий, работающих параллельно. А это уже экономия в чистом виде и вполне убедительный аргумент для бизнеса.
Пока критической ситуации не возникло, многие воспринимают технический долг как нечто абстрактное. К сожалению, часто осознание приходит, только когда бизнес теряет деньги или несёт репутационные потери. Но после этого он сразу понимает важность рефакторинга».
Николай Мельников,
руководитель компании Sebbia
Важный момент: договариваться о ресурсах и времени команды, которые будут тратиться на рефакторинг, лучше до начала работ. Потому что вовремя гасить технический долг — критично для любого программного продукта. С заказчиком необходимо говорить на его языке: объяснять финансовые риски и приводить примеры из жизни.
«У нас в BestDoctor есть договорённость, что один день в неделю каждый программист выделяет на работу с техническим долгом и автоматизацию, которая улучшает жизнь всей команде разработки. Этот день полностью посвящён не продуктовым, а инженерным задачам. Я рекомендую ввести обязательный процесс отдачи технического долга раз в неделю или раз в две недели. Это позволит не запускать его».
Михаил Корнеев,
тимлид в BestDoctor, автор YouTube-канала «Хитрый питон»
Качественный рефакторинг возможен, только если вы «брали» техдолг осознанно, понимали, что перфекционизм в этот момент навредил бы бизнесу, и фиксировали момент создания долга. Поэтому небрежно писать код и думать, что исправишь всё когда-нибудь потом, — плохая идея.
«Если уже сложилась ситуация, когда надо немедленно реагировать и что-то делать с техдолгом, значит, что-то не так с процессами. Нужно сразу планировать работу так, чтобы оставалось время на рефакторинг — от 5% до 33% рабочей недели. Команда должна знать, что у неё есть выделенное время для таких задач».
Николай Мельников,
руководитель компании Sebbia
Чек-лист: как не накапливать технический долг
Хотите изучить новый язык программирования или неизвестный фреймворк? Выбирайте подходящий среди курсов Skillbox.
Управление техническим долгом
Екатерина Сазонова, переводчик-фрилансер и студентка «Нетологии», специально для блога перевела статью Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом.
О проблемах разработки программного обеспечения, его оценке, контроле стоимости, тестировании написано огромное количество книг. Хочу поделиться с вами проверенными практиками, которые помогли мне как техническому менеджеру держать под контролем технический долг в растущем проекте.
Поддерживайте гибкость в нужных местах
Проектируйте программное обеспечение так же, как вы проектировали бы здание. Что-то в строительстве продвигается медленно, что-то — быстро. Некоторые компоненты, например, мебель или покраска стен, не имеют прямого отношения к самому зданию. При этом очень трудно поменять угол, под которым стены расположены друг к другу. Нужно расставлять приоритеты.
Понимание того, что может быть гибким в программе, а что — нет, относится не только к текущим требованиям, но и к будущим. Вот почему так сложно создавать софт. Вы не просто поставляете свой технологический продукт, вы пытаетесь предсказать будущее. А будущее покрыто мраком, всегда есть риск преждевременной оптимизации. Придется сделать выбор: какой компонент фундаментален, а какой можно легко изменить.
Слово software (дословно «мягкое изделие», появилось в противовес «твердому изделию» — hardware) искажает суть понятия, потому что подразумевает гибкость во всем. Гибкость во всем — это идеал, к которому нужно стремиться. Однако, правда такова, что более строгую систему с очень тесно связанными компонентами построить намного проще. К примеру, можно утверждать, что в монолитном приложении элементы связаны между собой сильнее, чем в наборе микросервисов. Очевидное преимущество монолитного приложения — в его простоте. Хотите написать хоть строчку кода для приложения, основанного на микросервисах? Изучите сначала гигантский список требований к обмену данными, координации и доступности элементов системы.
Это не значит, что микросервисы решают проблему связи между модулями. Они связывают модули с сетью, которая позволяет выстроить четкие, очерченные границы доменов, но само соединение неизбежно.
Гибкость стоит дорого. Не могу даже сосчитать, сколько раз я создавал что-то с представлением о том, как изменятся в будущем требования, а потом обнаруживал, что менять нужно именно «неподвижные» части, а гибкие не обязательно должны быть гибкими. Сначала я думал, что мне просто не везет, но теперь я понимаю, что просто ошибался при планировании.
Софт, в отличие от здания, устаревает по-другому. Если требования не меняются, фундамент не сдвинется и не начнет разрушаться, как это происходит со зданием. Программное обеспечение не изнашивается. Однако на его фундамент влияют новые требования. Стартапам очень сложно сделать правильный выбор. Эту проблему пытаются решить с помощью облачных сервисов, закладывая с самого начала возможность масштабирования. Оптимизация управления расходами и скоростью по мере того как вы будете расти потребует много фундаментальной работы. Даже с современными облачными решениями, механизмами управления микросервисами и так далее.
Рефакторинг для скорости
Рефакторинг — один из лучших способов увеличить общую скорость работы. Об этом уже было много сказано. В любой достаточно большой кодовой базе есть что порефакторить. Главное — рефакторить в нужном месте, там, где понадобится упрощение и гибкость в будущем. Чтобы это не напоминало игру в угадайку, будет правильным рефакторить до внедрения новых функций.
Прежде чем написать код, смиритесь с тем, что его придется выбросить
Простой способ уменьшить технический долг — понять, что любой код является лишь временным экспериментом. Например, вы решили создать отдельную ветку кода и быстро набросать прототип, который получится внедрить. Даже если с этой фичей все будет хорошо, вам придется написать код заново как следует, а старый выкинуть. Такое прототипирование специфично и несет много рисков: некоторым людям в вашей команде придется снизить свои стандарты. Однако этот метод сбережет ваше время.
Работайте с тестами и анализируйте код
Тестирование — это образ жизни, священная практика. Даже в маленьких проектах тестирование экономит больше времени, чем занимает сам процесс. Иногда это видно сразу, иногда — позже.
В компании должно быть принято проводить code review. Неважно, сколько тестов вы пишете, хорошо ли вы умеете рефакторить. Другие люди заметят моменты, которые вы пропустили. Ошибки. Баги. Опечатки. Да всё что угодно. Во многих компаниях по три пары глаз проверяют каждую строчку кода — считаю, это могло бы стать общим правилом.
Частота тестирования и проведения code review должна быть соизмерима с вредом, нанесенным проекту в случае провала. Исходный код требует более тщательной проверки, чем код интерфейса. Любое программное обеспечение, связанное с работой инсулиновой помпы, должно быть протестировано серьезнее, чем любое мобильное приложение. Можете себе представить команду, работающую над инсулиновой помпой, с лозунгом «Делай быстро и круши»? (мантра разработки Фейсбука и девиз Марка Цукерберга «Make fast and break things»).
Убейте плохо работающие фичи
Один мой знакомый инженер Ноа Торп как-то сказал мне: «Мы платим за каждую строчку кода каждый день». Чем меньше кода, тем меньше вы платите. Когда я работаю над проектом, мне важно, как работает каждая фича. Я регулярно собираю команду, чтобы решить, какие функции улучшить, а что убрать. Это значит временами признаваться себе в том, что фича, которая вам нравится, просто не работает.
Идеальная ситуация такова: вы понимаете, что фича неправильно будет работать еще до того, как пишете код. На первой линии защиты бумажные прототипы и тестирования на пользователях. Тем не менее, на вас всегда давят. Всегда слышен галдеж людей, использующих продукт и просящих добавить такие жуткие возможности, которые никогда не надо реализовывать. Или такие фичи, которые можно бы добавить, но позже. Вот где встречаются управление продуктом и техническое проектирование: даже если создать новую фичу — обычное дело, за это все равно придется платить.
Сведите зависимости к минимуму
Приходится платить и за зависимости тоже. Зависимости бывают внутренние и внешние. Внутренние — это библиотеки и фреймворки, от которых зависит ваше программное обеспечение. Внешние — это сервисы, с которыми связан ваш софт. От сервисов вы зависите вдвойне, потому что обычно с ними связаны и библиотеки.
Добавляя библиотеку к вашему проекту, вы платите за всю библиотеку и ваше пользование ей. Итак, вам нужно обосновать необходимость каждой библиотеки, каждого плагина. Даже самых маленьких. Они добавляются быстро. Если у вас взвешенный подход, вы удивитесь, насколько быстро вы продвинетесь.
Применять все эти методы проще, если они становятся общими принципами работы в вашей компании и для их использования создается благоприятная среда. Поддерживайте высокий уровень code review с запросами на включение кода (pull request). Продолжайте постоянно тестировать, поддерживая систему непрерывной интеграции (Continuous Integration). Ежемесячно обсуждайте основные фичи. Держите под рукой бумажные книги, которые рассказывают о правильных подходах, например, «Рефакторинг: улучшение структуры существующего кода» (“Refactoring: improving the design of the existing code”). И не забывайте их читать!
Важно четко понимать, что вы строите. Это будет тайное убежище на берегу моря, типовое жилье или стеклянный музей искусств? Ответ на этот вопрос должен совпадать у всей команды. Вот почему управление техническим долгом — это не только работа технического менеджера или разработчика. Это общая работа. Ведь она влияет на каждый шаг процесса разработки продукта, начиная с планирования.
Почему технический долг — это хорошо
Исключая тех, кому повезло быть богатыми, большинство людей занимают деньги, когда начинают свой первый бизнес. И они надеются, что эти инвестиции себя оправдают. Это пример того, как долг может быть хорошей штукой.
То же самое относится к техническому долгу. Бесчисленное множество статей в интернете рассказывают, как от него избавиться или хотя бы уменьшить. Все эти статьи показывают технический долг каким-то монстром, которого надо избегать. А если не получилось – то бороться изо всех сил.
Я приветствую технический долг в своей работе. Очевидно, что в общем случае не очень хорошо, когда вы кому-то должны. Но иногда долг может быть наименьшим из доступных зол. Доказать это очень просто – если бы технический долг был настолько страшен, то его никогда бы не было у крупных компаний (примечание переводчика: так себе аргументация, если честно).
В этом посте я хочу показать, насколько технический долг похож на обычный кредит, взятый на развитие бизнеса. И что нужно учитывать, принимая решение: брать такой кредит или не брать.
Что такое технический долг?
При разработке программ постоянно приходится балансировать между скоростью разработки и качеством того, что получается. Чтобы релиз случился вовремя, зачастую приходится жертвовать качеством разработки, используя «костыли» и «хаки». Исправление этого обычно переносят на будущие релизы – что, собственно, и называют «техническим долгом».
Технический долг возникает по многим причинам. Заказчики разработки могут больше фокусироваться на сроках и функциональности, нежели на исправлении старых проблем и создании надежного фундамента для дальнейшей разработки. В вырожденных случаях заказчики вообще игнорируют эти вещи, требуя от команды только «фичей в срок».
В конечном итоге, технический долг приводит к проблемам у пользователей, которые постепенно прекращают пользоваться продуктом. А игнорирование технического долга как разработчиками, так и менеджерами только способствует его накоплению.
Когда брать технический долг
Понимание того, когда необходимо сделать релиз за счет технического долга – это и искусство, и наука.
При взятии кредита одна из самых важных вещей – это процентная ставка. Очевидно, что брать кредит у акулы-ростовщика с высоким процентом является не самой лучшей идеей.
То же самое относится и к техническому долгу. Вам необходимо понять, какой именно «процент» вы будете по нему платить, основываясь на изложенных ниже правилах и здравом смысле. В большинстве случаев технический долг — это очень неплохая штука, – до тех пор, пока выплачиваемые каждый месяц проценты находятся в рамках разумного.
Для вычисления «процентной ставки» технического долга я предлагаю следующие приемы:
— Является ли код частью основной функциональности вашего продукта? Если да, то технический долг может иметь очень высокую цену. К примеру, наша команда Logz.io без проблем берет технический долг при разработки внутренних консолей управления или эзотерической функциональности для единичных клиентов. Но мы прикладываем все усилия, чтобы не иметь технического долга в нашей основной функциональности: обработке логов и аналитике.
— Сложности в будущем? Как технический долг отразится на последующую разработку? Какое влияние он окажет на смежную функциональность и задачи? Если разрабатываемые функции являются периферийными и не планируются к активному использованию в ближайшие месяцы, то технический долг может принести пользу и освободить время разработчиков для работы надо основным продуктом.
— Цена последующего устранения «костылей»? Очень часто исправление «заплаток» может требовать сложного апгрейда между версиями, потери обратной совместимости или вкладывания значительных сил в рефакторинг кода. Это означает, что в таких случаях «процентная ставка» будет очень высока.
— Влияние на клиентов? Какое влияние окажут использованные «костыли» и «заплатки» на ваших пользователей? Если они приведут к появлению багов раз в месяц – насколько это будут неприятные баги и что будут делать ваши пользователи в случае их появления?
Не бойтесь технического долга
Технический долг – это то, с чем нам приходится сталкиваться время от времени. И все сводится к вопросу, который экономисты формулируют как «цена возможности», то есть для того, чтобы сделать «X» нужно вначале сделать «Y».
Если ваша команда потратит день на исправление «заплаток» и «костылей», то этот день не будет потрачен на разработку новой функциональности. Точно так же, день работы над новыми фичами не будет потрачен на исправление старых багов.
Посмотрите на картину разработки с высоты руководства компании. Каждый доллар, который потрачен на разработку, уже не потратить на маркетинг, административные расходы и другие нужные для бизнеса вещи. То же самое работает в обратную сторону. Решения принимаются на основе приоритетов, и технический долг в большинстве случаев имеет низкий приоритет.
Приведу аналогию из мира финансов. Предположим, у компании есть обычный, не технический долг в миллион рублей. И выручка в размере полутора миллионов в месяц. Нужно ли компании сразу же выплатить весь долг? Конечно нет. Ведь оставшейся половины миллиона не хватит на выплату зарплат, аренды и других нужных вещей.
Правильным решением будет постепенная выплата долга. До тех пор, пока прибыль растет быстрее, чем выплаты по долгу, он не является чем-то плохим. Он является инвестированием.
Я приветствую технический долг, потому что он показывает, что мы растем как компания: релизим новые фичи и продукты, которые помогают нашим клиентам работать с логами. Если команда разработки тратит слишком много времени на исправление незначительных «костылей», то это приносит не пользу, а риск стагнации.
Ничто не совершенно – особенно в разработке программ. Я прекрасно понимаю, что разработчики гордятся своей работой и хотят видеть безглючный софт, но стараюсь смотреть на картину целиком и учитывать нужды не только разработки, но и компании (примечание переводчика: в большинстве случаев программисты хотят домой и пива, но, возможно, в кремниевой долине немного не так).
Приходит время, когда мы уменьшаем технический долг. Но это не настолько важно, как об этом думают большинство программистов. В будущем я продолжу это обсуждение и расскажу о лучших приемах для уменьшения технического долга – но не раньше, чем это будет необходимо.
От переводчика: также рекомендую прочитать одну из статей нашего технического евангелиста, посвященную техническому долгу. У него все описано в чуть более мрачных тонах, видимо, не везло человеку на стартапы с хорошим
финансированием.