Мастерство техдолга

nponeccop — 18.12.2024 Тут на Кворе был дебильный вопрос "Может ли QA помочь с техдолгом?" и аналогично же дебильные ответы, из которых стало ясно, что народ не понимает, что такое техдолг. Клод справился даже лучше, чем я предполагал, в плане идей, но как обычно страдают writing skills.

Unintentional technical debt is the accumulation of suboptimal code, architectural compromises, and design shortcuts that occur naturally during the software development process. Unlike its intentional counterpart, this form of debt is not a deliberate strategy but a byproduct of:

• Rapidly changing requirements


• Knowledge gaps


• Time constraints


• Complex problem-solving


• Individual developer approaches

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

Делают они это бессистемно, и то. что я вижу "сразу", просто, например, исходя из зон ответственности модулей/separation of concerns, у них получается через полгода и 15 переписываний. Тем не менее, по ключевой метрике -- времени написания интеграции с очередным платежным API -- мы опережаем ожидания по индустрии в 5 раз - вместо 2 недель 3 дня.

Managing unintentional technical debt is not about elimination, but about creating a sustainable ecosystem of continuous improvement.

Successful technical debt management recognizes that:

• Developers are creative problem-solvers


• Perfection is the enemy of progress


• Context matters more than absolute standards

It requires:

• Trust in the development team


• Flexible governance


• Continuous learning


• Shared responsibility

Allocate dedicated time and resources for debt management

• Quarterly debt reduction sprints


• 10-20% of development capacity reserved for refactoring


• Explicit recognition of debt management as a critical development activity

У нас так и получилось "само собой", изобрели велосипед.

Ключевыми моими достижениями, как я считаю, было убедить всех (и разрабов, и руководство), что

• Часто можно сказать "нет" на запрос клиента, и ничего не случится. Таким образом мы не впали в creeping featurism


• Отдача техдолга -- это такая же "нормальная" активность в проекте, как и добавление фич и исправление багов, и надо выделять на это время


• Не надо играть в игру "я заимплеменчу эту фичу за 5 дней! а я за 3!", что реалистичные эстимейты с заложенным запасом на ошибки и доведение до ума всех стейкхолдеров реально устроят

Ещё важно понимать техдолг в разрезе управления проектными рисками (не только техническими), и что, как и финансовое кредитование, создание техдолга может быть как "живительным притоком капитала", так и "кабальным бременем, приведущим к банкротству".

В этом плане желание не накапливать техдолг сродни желанию делать startup с использованием friends-and-family funding, а желание не отдавать техдолг сродни набиранию бессмысленных кабальных кредитов. И то и другое плохо, приходится балансировать, притом никто толком не знает, как. Но у нас вот пока получается.

Оставить комментарий

Популярные посты:

• Архив