Технический урон

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

Мы считаем, что негативное влияние этой аналогии на современную разработку ПО огромно. Финансовый долг — это обыденность для большинства людей: ипотека, кредитные карты, автокредиты. Идея накопления процентов выглядит вполне нормальной, особенно при низких процентных ставках. Доступ к долговым инструментам воспринимается как отличный способ быстрее достичь желаемого.

Технический долг имеет совсем другую сущность. Разработчики нередко увольняются из-за огромного технического долга. Не редкость, когда люди увольняются в первый день, увидев ужасающее состояние кодовой базы. Согласно последнему опросу Stack Overflow, технический долг — это главная проблема для разработчиков, которую назвали 63% опрошенных. Технический долг лишает разработчиков морального удовлетворения от работы, значительно усугубляя уровень стресса. Переписывание всего кода из-за неустранимого технического долга стало нормой в индустрии.

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

Вот почему и.-ф. метод вводит новый термин — «технический урон». Он охватывает всё, что мешает созданию безупречного и бесперебойного опыта и для пользователей (user experience), и для разработчиков (developer experience). Понятие включает дефекты, нечитаемый или запутанный код, неправильные конфигурации и сломанные шаблоны разработки — всё это является техническим уроном.

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

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

Баги — это антиработа

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

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

И.-ф. метод не использует отдельные карточки для дефектов. Вместо этого платформа создает отдельный сектор в каждой итерации функции. Это значит, что каждый дефект должен быть создан в той итерации функции, в ходе выполнения которой этот дефект был допущен. Кто-то может сказать, что это приведет к токсичной атмосфере и поиску виноватых. И.-ф. метод считает это встроенной радикальной прямотой (radical candour). Метод подразумевает, что профессионалы будут брать ответственность за качество своей работы.

Капля дегтя в бочке меда

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

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

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

В конечном итоге деградация кода достигает точки невозврата, люди уходят, а новые менеджеры объявляют, что весь код нужно переписать, что ведет к огромным затратам для бизнеса. Канбан создаёт идеальные условия для «смерти от тысячи бумажных порезов».

Информационные бункера — это технический урон

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

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

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

Технический ущерб — это развивающийся термин, и мы будем обсуждать его с сообществом.