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

Автор оригинала: Eric Higgins
  • Перевод
Выигрыш невозможен. Вы только решаете, насколько быстро проиграть


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

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

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


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

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


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

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

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


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

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

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


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

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

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

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


Game over

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

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

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

Баг на миллион долларов


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

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

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

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

Выплата не всегда окупается


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


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

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

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

Подробнее
Реклама

Комментарии 13

    +5
    В тетрисе нельзя закрыть ячейку не заполнив верхние пустоты в нужном порядке. А в работе можно.
    Красивая аналогия, но ошибочная.
      +7
      Если технический долг можно уменьшать в произвольном порядке, то это не долг, а должок. Как две пустоты в тетрисе одна над другой, открытые сверху.
        +3

        Проблема ещё в том, что в тетрисе вы ясно видите, где у вас ямы (технический долг), и видите их всегда. Даже дав управление другому человеку — он поймёт, где болит.
        В жизни чаще всего не так — ты не всегда знаешь, в каких местах у тебя больше, а в каких меньше технического долга, и насколько он опасен или может помешать в будущем.
        Возможно, этот кусок кода вообще никогда больше не понадобится (этот продукт оказался не востребованным), и его можно просто выкинуть и забыть, а в тетрисе так нельзя.
        ПС: ненавижу, когда вещи из жизни начинают сравнивать с чем-то вроде на первый взгляд похожим, но не похожим по многим остальным параметрам, притянутым за уши. Особенно наши заокеанские друзья писатели любят измеряьб всё в футбольных полях, самолётах и школьных автобусах (которых у нас конечно же нет, зато есть тетрис).

          +2
          Еще добавлю вот что: пустоты в тетрисе — ассоциация на технический долг. Бывает так, что на момент написания — вы использовали все самые «современные» методы разработки ПО. Но через 5-10 лет ваш код окажется не таким уж продуманным(на него невозможно применить современные методы разработки ПО/язык становится редкоиспользуемым (привет scala)/появляется новый несовместимый софт angular1/angular4 итд итп), откуда ни возьмись появляются пустые клетки (которых раньше небыло). А еще через какое-то время, эта дыра расширяется. Через еще какое-то время вы понимаете, что технический долг ужасен, и проще переписать программу с нуля.
          В тетрисе же дыры не появляются и не растут.
          0
          Ну нет! Позвольте, так это всё, что выше оказывается технический долг? Я так работать не согласен! Шучу, конечно. Но в программе же наоборот есть места, которые уж точно делать не надо! Не нужно же всё заполнять, чтобы пустот не было!? Может что-то надо оставить пустым? )))
            0
            > Но в программе же наоборот есть места, которые уж точно делать не надо!

            Бывает, да, что кредитор помирает раньше должника :)
              0
              Ну это надо ооочень долго писать.
                +1

                Достаточно, чтобы один заказчик уволился, пришел другой с "новым видением продукта"

          +1
          «Технический долг» — это уже само по себе аналогия. А тут аналогия на аналогию. Для аналогий нормально быть ошибочными в чем-то.
            0
            Иногда не можно. Если в фундамент заложена пачка граблей, на которых держатся последующие костыли, из которых собран последующий велосипед…
            Тут ключевое — время. Цигель-цигель.
            0
            промахнулся
              +1

              Тетрис похож на технический долг неправильными ходами игрока, когда фигура ставится не туда, и образуются пустоты.
              Аналогия уместная в том смысле, что технический долг (особенно преднамеренный, по принципу "и так сойдёт") без возможности или желания от него избавляться нарастает, как снежный ком.
              Чем больше косячить (ставить новые фигуры неправильно), тем быстрее это приведёт весь проект (текущий игровой сеанс) к стагнации и проигрышу.

                0
                хорошая аналогия, автор молодец

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

                Самое читаемое