Технический долг
#разработка
Прежде всего, большое спасибо всем, кто написал комментарии к предыдущему посту. Было интересно почитать их, а о некоторых экзотических решениях даже не слышал. Это повод почитать комментарии и познакомиться с новыми решениями.
Сегодня хотел бы коснуться такой вещи как технический долг. Возможно, не каждый слышал об этом.
В одной статье встретил отличную аналогию понятия «технический долг» — игра тетрис. Думаю, все играли в эту игру и отлично ее представляют.
Процесс разработки продукта — это и есть сама игра. Команда менеджеров и разработчиков работает над тем, чтобы создавать некоторые фичи и доставить их пользователю. Так вот, успешное создание фичи — это завершение одной линии в тетрисе.
Но часто бизнес требует фичи, которые ведут к компромиссу в коде, чтобы сделать новую функциональность вовремя. Или же случается так, что невозможно сделать фичу без костылей. Частым вариантом является поддержка старой и новой версии фукнции, пока все пользователи не обновятся. Все эти сценарии создают технический долг в коде. И такие вещи подобны пустым клеткам при игре в тетрис.
Писать без технического долга большой проект невозможно. Он будет всегда, и важно балансировать между скоростью доставки фич и постепенным удалением этих сценариев. Так же, как и в тетрисе: можно играть с пустыми клетками внизу, но важно, чтобы их не накопилось слишком много, потому что это сделает невозможным создание новых фич.
Еще интересно то, что со временем в бизнес становится все тяжелее играть, также как и в тетрис. И цена ошибки растет, и скорость доставки фич тоже. Ну и как и в тетрисе: нельзя «выиграть бизнес», так как нет финишной черты. Каждый только контролирует то, насколько медленно он проигрывает.
#разработка
Прежде всего, большое спасибо всем, кто написал комментарии к предыдущему посту. Было интересно почитать их, а о некоторых экзотических решениях даже не слышал. Это повод почитать комментарии и познакомиться с новыми решениями.
Сегодня хотел бы коснуться такой вещи как технический долг. Возможно, не каждый слышал об этом.
В одной статье встретил отличную аналогию понятия «технический долг» — игра тетрис. Думаю, все играли в эту игру и отлично ее представляют.
Процесс разработки продукта — это и есть сама игра. Команда менеджеров и разработчиков работает над тем, чтобы создавать некоторые фичи и доставить их пользователю. Так вот, успешное создание фичи — это завершение одной линии в тетрисе.
Но часто бизнес требует фичи, которые ведут к компромиссу в коде, чтобы сделать новую функциональность вовремя. Или же случается так, что невозможно сделать фичу без костылей. Частым вариантом является поддержка старой и новой версии фукнции, пока все пользователи не обновятся. Все эти сценарии создают технический долг в коде. И такие вещи подобны пустым клеткам при игре в тетрис.
Писать без технического долга большой проект невозможно. Он будет всегда, и важно балансировать между скоростью доставки фич и постепенным удалением этих сценариев. Так же, как и в тетрисе: можно играть с пустыми клетками внизу, но важно, чтобы их не накопилось слишком много, потому что это сделает невозможным создание новых фич.
Еще интересно то, что со временем в бизнес становится все тяжелее играть, также как и в тетрис. И цена ошибки растет, и скорость доставки фич тоже. Ну и как и в тетрисе: нельзя «выиграть бизнес», так как нет финишной черты. Каждый только контролирует то, насколько медленно он проигрывает.