Не спешите выкидывать свои старые визитки!

После того, как переходишь на новое место работы, остается целая куча неактуальных визиток. Но не спешите их выбрасывать, если они односторонние: их можно использовать для составления списков товаров, когда собираетесь в магазин или на рынок. Размер визитки будет в самый раз, чтобы вместить количество товаров, покупаемых за один заход.

Единственный минус - на оборотной стороне такого списка будет написано ваше имя и , возможно, контакты, так что лучше его не терять. :-)

Постоянная техническая задолженность

На этой неделе как-то за чаем мы с коллегами как-то разговорились о принципах разработки ПО.

Я рассказывал о метафоре технической задолженности (Technical Debt), придуманную Уордом Каннингемом (Ward Cunningham). Развивая мысль, лежащую в основе этой метафоры, я озвучил вывод, что лучше изначально все делать правильно и по уму, пусть и несколько дольше, лишь бы не наращивать техническую задолженность лишний раз.

Одна из коллег заметила, что это как-то не сочетается с таким принципом гибкой разработки, как YAGNI. Я как-то попытался объяснить это противоречие, но мне свое объяснение не очень понравилось. Это заставило меня задуматься.

Вообще, мысли, стоящие за этими двумя выражениями, не находятся в прямом противоречии. В противоречии находятся их крайние вариации. И это лишь еще одно подтверждение того, что в нашей работе всегда будет полно компромиссов, любую концепцию надо рассматривать критично и применительно к случаю (см. статьи No Best Practices и Better Best Practices), и ничему нельзя следовать слепо.

Но больше всего меня заставило задуматься возникшее понимание того, что техническая задолженность не может быть равна нулю в принципе (вернее, теоретически может, но на очень короткий срок). Статья Стива МакКоннелла (Steve McConnell), которую я прочитал после, хорошо объясняет почему это нормально и разумно.

Но я бы хотел отметить один тип непреднамеренной технической задолженности, не выделенный в той статье. Даже если техническая реализация системы идеально соответствует предметной области и ожиданиям заказчика, изменения в последних, происходящие со временем, будут постепенно перемещать сделанные технические решения качественно из категории "ясные и правильные" ("clean and correct") в категорию "сделанные наспех и неряшливые" ("quick and dirty"). Добавление этого типа позволяет четко определить рефакторинг, как собственно способ сокращения существующей технической задолженности.

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

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

P.S. Ссылки на ресурсы, посвященные раскрытию метафоры технической задолженности, я собрал здесь.

P.P.S. Метафоры Adapt To Adapt и Code Momentum выражают очень близкие мысли к метафоре технической задолженности.

Поехали!

Ну что сказать, скоро 29, а дневничок-то пустоват. Буду потихоньку исправлять ситуацию. Тем более, что уже есть, что сказать...