Хабрахабр

[Перевод] Технический долг как тетрис

Выигрыш невозможен. Вы только решаете, насколько быстро проиграть

Какой следующий ход?

Помню, как сыграл в первый раз на Nintendo Game Boy моего друга. Многим нравится тетрис, мне тоже. Тетрис не только одна из лучших игр всех времён, но и отличная аналогия для технического долга. Возможно, у вас в голове тоже застряла та мелодия. Она даёт общее понимание технического долга и его воздействия.

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

Сначала задачи попроще, на низком уровне сложности

Завершение строки в тетрисе похоже на выпуск функции. В софтверных компаниях менеджеры по продуктам/проектам вместе с разработчиками определяют, какой код будет написан и отправлен клиентам в ближайшем релизе.

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

Выпуск сложной функции требует завершения нескольких строк.

Или изменения в стратегии продукта несовместимы с предыдущим дизайном, требуя дополнительных усилий для миграции клиентов или поддержки как «новой», так и «старой» логики. Часто бизнес-потребности (новые функции, новые продукты) ведут к компромиссам в коде (хаки, обходные пути), чтобы не просрочить дедлайн.

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

Скрытый пропуск в тетрисе представляет собой технический долг. Подобные сценарии создают технический долг в рамках кода.

Это нормально. У любого кода есть технический долг. Вы можете продолжать играть с несколькими пропусками.

Похоронен в техническом долге

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

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

Это держит вас в игре. Погашение технического долга делает вас конкурентоспособными.

Game over

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

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

Подобно бизнесу, слишком много пробелов в тетрисе ведёт к проигрышу.

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

Система была написана с большой осторожностью и благими намерениями — не столько неряшливо, сколько негибко. Основная задача этого кода состояла в том, чтобы пройти по счетам всех клиентов, рассчитать каждого — и отправить информацию в API для выставления инвойсов. Никаких тестов. Монолитная функция. Документация практически отсутствовала. Очень мало логов. Систему написал более пяти лет назад один из основателей. Происходила какая-то необъяснимая рандомизация. Единственные изменения с тех пор внёс один из первых сотрудников, который уже отсутствовал в компании.

Счета выставлялись. Была ли проблема вообще? Не было никаких признаков проблемы. Компания зарабатывала деньги. Всё это говорило против рефакторинга, но мы знали, что грядут большие изменения: эта функция не сможет масштабироваться для наших нужд, и будет гораздо проще двигаться дальше, если упростить эту чаcть.

Тогда-то мы и обнаружили, что на самом деле починили. За один спринт мы переработали функцию и добавили некоторые столь необходимые логи. Старый код втихую отваливался по таймеру — и некоторые клиенты не обрабатывались. Кто-то из бухгалтеров остановился у наших столов и спросил, почему количество исходящих инвойсов неожиданно увеличилось. Она скрывала любые модели, которые могли бы дать понять, что какому-то клиенту не выставили инвойс. Странная рандомизация? Когда мы провели оценку, то насчитали недостающих инвойсов более чем на $1 млн за год.

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

Найти правильный баланс технического долга

К сожалению, ответ в том, что это сложно — и это всегда сводится к балансу. Хотел бы я дать мудрый совет, когда нужно расплачиваться с техническим долгом. И наоборот, ваша компания может работать в действительно грязном коде, но который радует клиентов, а деньги текут рекой. У вас может быть самый чистый, самый хорошо протестированный код в мире, но не быть клиентов.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть