На этой неделе как-то за чаем мы с коллегами как-то разговорились о принципах разработки ПО.
Я рассказывал о метафоре
технической задолженности (Technical Debt), придуманную Уордом Каннингемом (Ward Cunningham). Развивая мысль, лежащую в основе этой метафоры, я озвучил вывод, что лучше изначально все делать правильно и по уму, пусть и несколько дольше, лишь бы не наращивать техническую задолженность лишний раз.
Одна из коллег заметила, что это как-то не сочетается с таким принципом гибкой разработки, как
YAGNI. Я как-то попытался объяснить это противоречие, но мне свое объяснение не очень понравилось. Это заставило меня задуматься.
Вообще, мысли, стоящие за этими двумя выражениями, не находятся в прямом противоречии. В противоречии находятся их крайние вариации. И это лишь еще одно подтверждение того, что в нашей работе всегда будет полно компромиссов, любую концепцию надо рассматривать критично и применительно к случаю (см. статьи
No Best Practices и
Better Best Practices), и ничему нельзя следовать слепо.
Но больше всего меня заставило задуматься возникшее понимание того, что техническая задолженность не может быть равна нулю в принципе (вернее, теоретически может, но на очень короткий срок).
Статья Стива МакКоннелла (Steve McConnell), которую я прочитал после, хорошо объясняет почему это нормально и разумно.
Но я бы хотел отметить один тип непреднамеренной технической задолженности, не выделенный в той статье. Даже если техническая реализация системы идеально соответствует предметной области и ожиданиям заказчика, изменения в последних, происходящие со временем, будут постепенно перемещать сделанные технические решения качественно из категории "ясные и правильные" ("clean and correct") в категорию "сделанные наспех и неряшливые" ("quick and dirty"). Добавление этого типа позволяет четко определить рефакторинг, как собственно способ сокращения существующей технической задолженности.
Мне также пришла в голову мысль, что такие вещи, как изначально выбранный путь separation of concerns и использования подходящих архитектурных шаблонов в основе системы позволяет в дальнейшем получать техническую задолженность, так сказать, "под меньшие проценты". Добавление уровня косвенности также позволяет уменьшить процент. То есть, если вам надо что-то сделать наспех и неряшливо, то постарайтесь это изолировать в отдельный модуль.
Таким образом, можно расширить рекомендацию из статьи Стива до "Будьте уверены, что вы имеете правильный тип технической задолженности, и под наименьшие проценты."
P.S. Ссылки на ресурсы, посвященные раскрытию метафоры технической задолженности, я собрал
здесь.
