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