[Перевод] Технический долг как тетрис
Выигрыш невозможен. Вы только решаете, насколько быстро проиграть
Какой следующий ход?
Многим нравится тетрис, мне тоже. Помню, как сыграл в первый раз на Nintendo Game Boy моего друга. Возможно, у вас в голове тоже застряла та мелодия. Тетрис не только одна из лучших игр всех времён, но и отличная аналогия для технического долга. Она даёт общее понимание технического долга и его воздействия.
Расскажу ещё историю из личного опыта, как моя команда уменьшила технический долг в каком-то биллинговом коде и при этом исправила ошибку на миллион долларов в год.
Сначала задачи попроще, на низком уровне сложности
В софтверных компаниях менеджеры по продуктам/проектам вместе с разработчиками определяют, какой код будет написан и отправлен клиентам в ближайшем релизе. Завершение строки в тетрисе похоже на выпуск функции.
Сложные функции вполне реализуемы почти без увеличения технического долга
Выпуск сложной функции требует завершения нескольких строк.
Часто бизнес-потребности (новые функции, новые продукты) ведут к компромиссам в коде (хаки, обходные пути), чтобы не просрочить дедлайн. Или изменения в стратегии продукта несовместимы с предыдущим дизайном, требуя дополнительных усилий для миграции клиентов или поддержки как «новой», так и «старой» логики.
Небольшой технический долг является нормальным и управляемым
Подобные сценарии создают технический долг в рамках кода. Скрытый пропуск в тетрисе представляет собой технический долг.
У любого кода есть технический долг. Это нормально. Вы можете продолжать играть с несколькими пропусками.
Похоронен в техническом долге
Слишком большой технический долг не позволяет за разумное время выпустить новую функцию или исправить ошибку.
Эту проблему не решить добавлением новых разработчиков или, что более драматично, заменой существующих. Это называется техническим долгом: в какой-то момент его придётся выплатить.
Погашение технического долга делает вас конкурентоспособными. Это держит вас в игре.
Game over
Подобно управлению бизнесом, в тетрисе сложность со временем растёт. Фигуры движутся быстрее, и за ними труднее угнаться.
Как и в бизнесе, здесь невозможно выиграть. Нет реальной финишной черты. Вопрос только в том, как скоро вы проиграете.
Подобно бизнесу, слишком много пробелов в тетрисе ведёт к проигрышу.
Не так давно моей команде поручили обновить логику выставления счетов/инвойсов в коде нашего продукта для поддержки новых ценовых планов, нового платёжного процессора и улучшения всего процесса выставления счетов в целом. Некоторые детали ещё выяснялись, поэтому мы использовали это время для глубокого погружения в существующий код, чтобы дать более точные оценки предстоящих изменений.
Основная задача этого кода состояла в том, чтобы пройти по счетам всех клиентов, рассчитать каждого — и отправить информацию в API для выставления инвойсов. Система была написана с большой осторожностью и благими намерениями — не столько неряшливо, сколько негибко. Монолитная функция. Никаких тестов. Очень мало логов. Документация практически отсутствовала. Происходила какая-то необъяснимая рандомизация. Систему написал более пяти лет назад один из основателей. Единственные изменения с тех пор внёс один из первых сотрудников, который уже отсутствовал в компании.
Была ли проблема вообще? Счета выставлялись. Компания зарабатывала деньги. Не было никаких признаков проблемы. Всё это говорило против рефакторинга, но мы знали, что грядут большие изменения: эта функция не сможет масштабироваться для наших нужд, и будет гораздо проще двигаться дальше, если упростить эту чаcть.
За один спринт мы переработали функцию и добавили некоторые столь необходимые логи. Тогда-то мы и обнаружили, что на самом деле починили. Кто-то из бухгалтеров остановился у наших столов и спросил, почему количество исходящих инвойсов неожиданно увеличилось. Старый код втихую отваливался по таймеру — и некоторые клиенты не обрабатывались. Странная рандомизация? Она скрывала любые модели, которые могли бы дать понять, что какому-то клиенту не выставили инвойс. Когда мы провели оценку, то насчитали недостающих инвойсов более чем на $1 млн за год.
Хотя история полностью правдива, выплата технического долга не всегда имеет такой драматический эффект. Нам повезло.
Найти правильный баланс технического долга
Хотел бы я дать мудрый совет, когда нужно расплачиваться с техническим долгом. К сожалению, ответ в том, что это сложно — и это всегда сводится к балансу. У вас может быть самый чистый, самый хорошо протестированный код в мире, но не быть клиентов. И наоборот, ваша компания может работать в действительно грязном коде, но который радует клиентов, а деньги текут рекой.
Я могу только сказать, что и владельцы продукта, и разработчики должны понимать суть технического долга и что его нельзя избежать навсегда. В конце концов, как и в тетрисе, здесь вы никогда не сможете победить.
