Техдолг. Часть 1. Токсичная метафора "долга" заставляет нас самих быть токсичными Давно хотел написать серию постов про техдолг, и, видимо, время пришло — в очередной раз в проекте поймал себя на мысли, что разные люди закладывают в это слово разный смысл: для разработчика это «грязный код, который надо переписать» (а часто и вообще любой чужой код); для архитектора это неправильная/неоптимальная архитектура с использованием не тех паттернов или инструментов; для менеджера это причина снижения скорости команды и повышения количества ошибок; для бизнеса это «чужие ошибки, за которые платить приходится нам». То есть, по сути, если собрать в одной комнате тимлида, разработчика и CPO, они вечно будут спорить о смыслах, которые в это слово вкладываются. Нужно ли удивляться, что защита священных 20% от мощности команды на техдолг превратилась в отдельную дисциплину и навык для менеджеров. А если вдуматься еще глубже — метафора «долга» в этом термине начала работать против нас: ведь при оплате неизвестного долга в первую очередь хочется узнать, кто взял, под какие условия и кому теперь платить. При этом в 9 из 10 случаев никакого классического договора «давайте сделаем сегодня быстро, а завтра добавим качество» не было — это просто регулярные работы по рефакторингу, улучшению дизайна, оптимизации и т.д. На заводе это бы назвали «Техобслуживание и ремонты», в авиации — регламентное обслуживание, на станции ТО автомобилей — просто ТО: главное, что поиска виноватых бы не было. Наоборот, мало кто захочет ездить в автомобиле без ТО или самолете, который не прошел обслуживание. Поэтому моя первая мысль о техдолге — мне кажется, пора перестать называть его техдолгом, а лучше просто «рефакторинг», как часть регулярной работы по оптимизации и улучшению качества. В следующем посте — про то, откуда термин техдолг появился (Каннингем и Фаулер) и почему тогда метафора была уместна, а сейчас уже нет.