Мне всегда сложно было объяснить даже самому себе термин «технический долг». Никогда не было понятно, кто, кому, за что и сколько должен. И, если это долг, то как его выплачивать и можно ли выплатить полностью? А можно ли сделать так, чтобы должны были мне?
Совсем недавно прочитал статью Криса Гейла из Yammer, который вводит понятие «цена сложности» (complexity cost), которое мне гораздо ближе и понятнее. Цена сложности описывает ровно тот же аспект разработки сложных систем, что и технический долг, только вносит, с моей точки зрения, большую ясность.
Идея крайне простая — чем сложнее проект, тем больше усилий тратится на его поддержку, тем дороже его менять. Хотя в чистом виде «сложность» мы измерить не можем, но это утверждение считают верным, наверное, все инженеры.
Крис пишет в своей статье, что время, которое необходимо потратить на то, чтобы сделать новую функциональность — это самая малая часть затрат на эту функциональность. Он приводит пример, как он сделал что-то для Yammer за 1 час, а в течении следующих 5 лет потратил 40 часов, рассказывая другим инженерам, что это такое и как оно работает. А это значит, что суммарно на эти разговоры ушло не меньше 80 часов, ведь другой инженер тоже тратил на это свое время.
Сложность можно разделить на два вида. Первый вид сложности — это количество функций, которые есть у системы. Второй вид сложности — это оверинжиниринг при реализации какой-то функции. И чем больше функций у продукта, тем дороже его поддержка и изменение. Этот вид сложности можно уменьшить только одним способом — убрать какую-то функцию. Крис пишет, что в Yammer после добавления новой функциональности, они какое-то время наблюдают за ней, и если она не используется и не приносит ценности, то ее убирают. Более того, они меряют, как используются все функции на сайте, для оценки того, во что стоит вкладывать усилия, а от чего можно отказаться.
Второй вид сложности — ненужная сложность, лечится только зрелым инженерным подходом. Вместо того, чтобы сделать что-то «круто» (эта болезнь есть не только у русских молодых инженеров), необходимо думать о том, как сделать что-то максимально просто. Либо упрощать что-то, что уже используется в проекте.
Например, в одном из моих проектов был планировщик задач, который изначально был «заточен под высокие нагрузки». В нем использовалась многопоточная архитектура, а внутри каждого потока использовались нити. Более того, был спроектирована многоуровневая процедура отката задач, которые выполнял планировщик. Но трезвое размышление показало, что количество задач, которые этот планировщик выполняет, достаточно мало, а многоуровневый откат сильно усложняет написание и поддержку проекта, при этом все равно все задачи откатывались целиком в случае возникновения ошибки. Мы потратили неделю на то, чтобы упростить планировщик, после чего и его код значительно уменьшился и стал гораздо проще.
Несколько раз мне приходилось защищать проекты от внедрения еще одной «быстрой» очереди сообщений, когда количество сообщений в день не превышало нескольких тысяч, и все отлично крутилось на БД, которая и так использовалась в проекте.
В нескольких проектах, которые мы консультировали, и на которых использовалась реляционная СУБД, мы избавлялись от MongoDB, значительно упрощая их поддержку.
Когда менеджер спрашивает: «Сколько времени займет сделать вот такую штуку?», — надо сразу подумать о том, что этот вопрос практически лишен смысла, потому что время поддержки и доработки во много раз превышают время создания новой функциональности.
Понятно, что проектов с нулевой сложностью не бывает, поэтому в любом проекте необходимо за сложность платить. Вопрос только в том, можно ли что-то сделать с проектом, чтобы сложности в нем стало меньше, а денег он приносил столько же. Это и есть управление сложностью — та задача, которую решает зрелый инженер.
А вопросы, которые я поставил в начале статьи, можно превратить всего в один: «Сколько мы переплачиваем за сложность?» Если бы эту цифру можно было посчитать в деньгах, то это и был бы «технический долг».
Автор: evtuhovich
