Когда Уорд Каннингем придумал фразу «технический долг», упоминание финансового долга было преднамеренным; у нас накапливается технический долг, когда мы сокращаем сроки, которые приносят нам немедленную выгоду (возможность поставки, время разработки, рыночная конкуренция), но при этом выплачиваются проценты, истощающие наши ресурсы [1]. Первые дни Facebook являются хорошим примером: PHP использовался в качестве основы для быстрой разработки, в то время как Цукерберг быстро экспериментировал с новыми функциями, но в конечном итоге это оказалось слишком большим недостатком масштабируемости и производительности, и долг был погашен путем перехода на C ++ [2]. Написание неаккуратного кода ничего не стоит; многие выдающиеся ораторы представляют свое собственное определение, но они согласны с тем, что ошибочный, поспешный или некрасивый код не является техническим долгом и, безусловно, бесполезен [3, 4, 5].

Эксперт по разработке программного обеспечения Мартин Фаулер считает, что технический долг обладает двумя качествами; преднамеренность и осторожность [6]. Преднамеренность - это когда вы решаете взять долг умышленно, тогда как осторожность - это мера того, как вы планируете погасить любой возникший долг. Мы думаем, что долг полезен только тогда, когда он обладает обоими этими свойствами.

Когда технический долг берется преднамеренно, мы можем создавать инструменты для мониторинга его воздействия и использовать показатели для определения оптимального способа борьбы с ним. Стив Фриман представляет аналогию с картой ураганов в своем выступлении «Руководство для блеферов по техническому долгу», чтобы продемонстрировать, как, когда долг хорошо отслеживается, команды могут погасить его в наиболее разумное время [3]. Когда долг берется неосознанно, может быть трудно определить, где был долг и как он повлиял на проект. Усилия могут быть дезорганизованы и никакая качественная оценка проекта не улучшается. Команды могут в конечном итоге взять на себя задачи, которые Дэвид Вандегрифт называет «возможно» проблемами технического долга [7]. Часто это вопросы личного вкуса, когда «фиксированная» версия не обязательно лучше по каким-либо объективным показателям.

Не менее важно, чтобы команды осторожно подходили к техническому долгу; Осознание долга и его влияния ценно только в том случае, если команда может его погасить. Twitter и Friendster боролись с масштабируемостью после быстрого накопления больших пользовательских баз. Долг был взят намеренно, чтобы конкурировать на рынке социальных сетей 2000-х годов. «Кит-сбой» Twitter, который появлялся, когда сайт был переполнен, был в конечном итоге убит за счет инвестиций в надежность сервиса [8]. Это включало переход от монолитной установки Ruby on Rails к нескольким независимым системам JVM, которые могли масштабироваться в соответствии с возросшим пользовательским трафиком [9]. Однако Френдстер расставил приоритеты по-другому. Плата была настолько сосредоточена на добавлении новых функций, таких как VoIP, чтобы превзойти своих конкурентов, что ее 40-секундное время загрузки страницы в конечном итоге привело пользователей к более новым платформам, таким как MySpace [10]. Twitter, который серьезно относился к выплате своего технического долга, теперь имеет более 300 миллионов активных пользователей, тогда как Friendster, который действовал неосторожно, теперь устарел. [11]

Иногда политика взятия технического долга позволяет избежать потери времени. Даже в проекте с бесконечными ресурсами некоторые исправления просто не стоит предпринимать. Freeman представляет пример фреймворков с открытым исходным кодом. Хотя они часто переполнены техническим долгом, они также хорошо работают, больше не подвержены частым изменениям и лучше с «заливкой бетона» [3]. Большинство проектов имеют ограниченный срок жизни, и некоторые долги стоит нести до конца. При правильном использовании технический долг может стать мощным инструментом, помогающим командам разработчиков действовать гибко и решать насущные проблемы. Тем не менее, команды должны сознательно брать на себя долги, чтобы понимать, как они влияют на их проект, и быть осторожными, чтобы не допускать постоянного приоритезации краткосрочных целей, ставящих под угрозу будущее проекта.

Написано с Джули Эмиль и Джеком Моррисоном

использованная литература

[1] Что такое технический долг? [Онлайн]. Доступно по адресу: https: //www.productplan.com/glossary/technical-debt/#: ~: text = Technical. [Проверено 19 февраля 2021 г.].

[2] Скрытые издержки и выгоды технического долга. [Онлайн]. Доступно по адресу: https://www.polymathlabs.co/blog/technical-debt. [Проверено 19 февраля 2021 г.].

[3] Стив Фриман: Руководство по техническому долгу для других людей - sclconf 2018. [Online]. Доступно с: https: //www.youtube.com/watch? V = jXpJVsv3Iec. [Проверено 19 февраля 2021 г.].

[4] Технический долг не является техническим - Einar w. Хозяин. [Онлайн]. Доступно по адресу: https: //www.youtube.com/watch? V = CXyNZYDO07Q. [Проверено 19 февраля 2021 г.].

[5] Theciocfoconversation: Technicaldebt - anaptterm? [Online]. Доступно с: https: //aws.amazon.com/blogs/enterprise-strategy/the-cio-cfo-conversation-technical-debt-an-apt-term/. [Проверено 19 февраля 2021 г.].

[6] Квадрант технического долга. [Онлайн]. Доступно по адресу: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html. [Проверено 19 февраля 2021 г.].

[7] Техническая задолженность нереальна. [Онлайн]. Доступно на сайте: https: //medium.com/swlh/technical-debt-isnt-real-8803ce021caa. [Доступно 22 февраля 2021 г.].

[8] Как Твиттер победил кита-неудачника. [Онлайн]. Доступно по ссылке: https://business.time.com/2013/11/06/how-twitter-slayed-the-fail-whale/. [Доступно 22 февраля 2021 г.].

[9] Новый рекорд твитов в секунду, да еще как! [Онлайн]. Доступно по адресу: https: //blog.twitter.com/engineering/en_us/a/2013/new-tweets-per-second-record-and-how.html, [доступ 22 февраля 2021 г.].

[10] Friendster потерял лидерство из-за невозможности масштабирования. [Online]. Доступно по адресу: http: //highscalability.com/friendster-lost-lead-because-failure-scale. [Доступно 22 февраля 2021 г.].

[11] Twitter: количество активных пользователей в месяц, 2010–2019 гг. [Онлайн]. Доступно по адресу: https://www.statista.com/statistics/282087/number-of-monthly-active-twitter-users/, [доступ 22 февраля 2021 г.].