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

Что такое технический долг?

Проще говоря, технический долг - это любое техническое сокращение, которое ускоряет текущую разработку за счет усложнения и замедления будущих изменений и дополнений, в результате чего общая стоимость этих функций выше, чем была бы без нее. Недавнее исследование CISQ пришло к выводу, что общая стоимость некачественного программного обеспечения в США в 2018 году составила 2,84 триллиона долларов, из которых 18,2% были отнесены на счет технического долга.

Мои изменения также влияют на будущее. Я могу найти быстрый способ добавить эту функцию, но это путь, который идет вразрез с модульной структурой программы, добавляя беспорядка. Если я пойду по этому пути, я сделаю это быстрее для себя сегодня, но замедлю всех остальных, кто будет иметь дело с этим кодом в будущие недели и месяцы. Как только другие члены команды сделают то же самое решение, легко изменить приложение может быстро накапливаться до такой степени, что каждое небольшое изменение требует многих недель усилий . - Мартин Фаулер

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

Скрытые затраты

Повышенная сложность

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

Увеличение количества ошибок и дефектов

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

Упущенная возможность

Хотя влияние технического долга на время разработки несколько легче заметить, обычно существует слепое пятно, когда речь идет о функциях и продуктах, которые никогда не разрабатываются. Области системы, которые, как известно, имеют большой технический долг, могут в конечном итоге оттолкнуть команды от разработки там новых функций, если учесть, какие усилия для этого потребуются и более высокий риск. Это не только мешает организации исследовать новые возможности и быстро выполнять итерацию, но во многих случаях решение не разрабатывать функцию принимается после того, как потрачены усилия на изучение и понимание проблем и сложностей соответствующей области системы, оценку усилий и обсуждение. альтернативы (такие как «быстрые и грязные» решения, которые увеличивают технический долг).

Пониженная предсказуемость

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

Усилия по управлению техническим долгом

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

Культура НИОКР

И последнее, но не менее важное: введение технического долга в систему без его исправления со временем также повлияет на культуру НИОКР и может побудить других сделать то же самое.

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

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

Пример

Допустим, у нас есть страница регистрации на нашем веб-сайте, и когда пользователь регистрируется, мы отправляем событие «регистрации» в наш поток событий, который в настоящее время используется только для аналитических целей. Теперь мы получаем новое требование отправлять электронное письмо после регистрации пользователя, которое предлагает ему запланировать сеанс обучения продукту. Мы создаем сервис, который использует эти события и отправляет электронное письмо сразу после регистрации пользователя. Все счастливы.
Через некоторое время на сайт добавляется новая услуга с другим потоком регистрации. Для этой услуги после регистрации не следует отправлять электронную почту. Разработчик, добавивший новую страницу регистрации, предлагает быстрое решение, при котором события «регистрации» не будут отправляться для этой страницы после проверки у менеджера продукта и аналитика, что это событие не используется для этой новой службы. Новая страница регистрации открыта, и все снова счастливы.
Давайте рассмотрим будущие последствия такого решения и затраты на него:

Общая сложность системы была увеличена - то, что должно было быть простым событием «регистрации», теперь имеет некоторую скрытую логику, при которой оно не всегда отправляется, и система запуска электронной почты теперь связана с этой логикой. Это повлияет на будущие изменения этих компонентов, требуя, чтобы многие люди были знакомы с этой логикой, например аналитики, которые теперь должны знать, когда они могут и не могут использовать это событие для анализа, или узнать об этом на собственном горьком опыте.

В будущем более вероятно возникновение ошибок, например, если добавлен новый поток регистрации, который невинно запускает событие «подписки», не имея намерения инициировать отправку электронного письма для пользователя. Если разработчик узнал об этом достаточно рано, ошибка может не появиться, но возникнет задержка в проекте, поскольку команда должна будет решить либо ее обойти, либо провести рефакторинг и устранить этот технический долг. Оба варианта приведут к незапланированной задержке проекта, что отрицательно скажется на предсказуемости.

Если команда решит обойти эту проблему, они, вероятно, добавят какую-то задачу «рефакторинга» в свой бэклог, которую нужно будет расставить по приоритетам, обсудить и, как правило, повторно обсудить до тех пор, пока этот долг не будет удален, что добавит к стоимости управление техническим долгом.

Заключение

В следующий раз, когда вы подумываете об увеличении своего технического долга, спросите себя (и других заинтересованных сторон) - намного ли выше ценность выпуска этой новой функции / продукта раньше, чем ценность следующих, которые она откладывает? В большинстве случаев ответ будет отрицательным - завтрашние возможности, вероятно, будут такими же неотложными, как и те, с которыми вы сталкиваетесь сегодня. Когда вы все же примете решение пойти «быстрым и грязным» путем, составьте твердый план на следующий день и убедитесь, что он хорошо изложен, чтобы все согласовали, что потребуется для дальнейшего развития этой системы или продукта в дальнейшем.

Хотелось бы услышать ваши мысли и комментарии!