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