Антихрупкость в IT - Александр Васильевич Бындю

Рис. 61. Нарастание техдолгов в зависимости от релиза

Что показывает нам график:

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

2. После релиза напряжение спадает. Если в команде есть опытные разработчики и дизайнеры, то они понимают, что без улучшения качества кода и макетов будет трудно двигаться вперёд. Во время планирования второго релиза в него закладываются работы по уменьшению техдолга. Поэтому по мере работы над вторым релизом мы доходим до зелёной точки, но на горизонте начинает маячить уже следующий дедлайн; всем не до техдолгов, опять работа кипит, опять техдолг растёт.

3. Этот сценарий повторяется от релиза к релизу. Чем больше мы работаем с проектом, тем больше мы платим за оставленные в коде долги, тем больше долгов мы копим.

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

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

Для ответа на эти вопросы давайте представим себе точки зрения на эту проблему разработчиков и руководителей.

Программисты видят причину

Сами создатели системы знают, что им мешает двигаться вперёд. Они каждый день видят магические числа в коде, дублирование кода, неконсистентность в макетах, отсутствие тестов, низкий уровень автоматизации и другие проблемы. Но по разным причинам стараются это игнорировать. Кто-то в силу своей некомпетентности считает такое положение вещей нормой, кто-то не хочет эскалации проблем наверх, кто-то просто хочет пилить задачи и не желает брать ответственность; причины могут быть самыми разными.

Руководители видят следствия

Крайне сложно объяснить человеку, который не разбирается в программировании и дизайне, почему мы в данный момент не можем позволить себе расширить нашу систему. Или почему вдруг стоимость поддержки системы стала расти. Почему нам требуется всё больше и больше времени на добавление функций, которые раньше довольно быстро добавлялись.

Попробуйте объяснить это в технических терминах, и вас попросят вернуться к работе и впредь не допускать подобных ситуаций. Если вы хотите открыть глаза на существование этой проблемы вашему руководителю, вам придётся говорить с ним с позиций его прибыли[99].

До тех, кто управляет деньгами, необходимо донести мысль, что технические долги = финансовые долги. Технические долги придётся выплачивать с процентами, причём реальными деньгами. Чем дольше мы будем тянуть с оплатой, тем выше будет выплата по долгу.

Стратегии уменьшения долга

Теперь рассмотрим различные стратегии уменьшения техдолга на более длительном промежутке времени (рис. 62).

Рис. 62. Нарастание техдолга в зависимости от выбранной стратегии

Для сравнения у нас есть три подхода:

1. Команда не заботится о качестве кода. Как уже было показано, этот способ ведёт только к полной остановке проекта. Наступает момент, когда проект проще выкинуть и написать заново.

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

3. Команда заботится о постоянном улучшении внутреннего качества системы. Только постоянная забота о качестве кода может на долгое время сохранить систему в рабочем состоянии.

Метрики технического долга

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

Измерить техдолг можно оценкой задач, которые направлены на снижение долга. Эти задачи должны быть у всех на виду, наравне с другими задачами, их нужно приоритизировать и брать в работу.

Численные параметры техдолга можно увидеть с помощью таких инструментов, как SonarQube. Кроме этого, в системы CI почти всегда встроены метрики кода, по которым строятся графики и настраиваются уведомления.

Если разработчики берут задачу по снижению технического долга, то, как следствие, после реализации задачи снижение станет заметным на графиках и в цифрах.

Внутреннее качество и антихрупкость

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

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

При этом нужно помнить, что внутреннее качество системы стоит очень дорого[100]. Речь даже не о человеко-часах, которые нужно вложить в это качество, а о привлечении и удержании на проекте грамотных инженеров, которые в состоянии создать и поддерживать высокое качество бесконечно долго. С другой стороны, если игнорировать вложения во внутреннее качество, то можно потерять проект. Поэтому я рекомендую очень внимательно относится к техдолгу и к инженерам, которые занимаются разработкой и дизайном.

Послесловие

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

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

Антихрупность в создании IT-продуктов

Когда Алексей Пименов, эксперт в Канбан-методе и управлении продуктами, читал черновик этой книги, он захотел уточнить, почему то, что я описываю, делает создание IT-продуктов именно антихрупким, а не просто гибким.

В своей книге я ориентировался именно на антихрупность создания IT-продуктов в том варианте, как описывает этот термин Нассим Талеб в книге «Антихрупкость». IT-продукт может, и я бы даже сказал должен, уметь меняться и мутировать как угодно и когда