Технический долг

«Сделаем как быстрее, понадобится — переделаем», — я слышал и говорил эту фразу достаточно часто чтобы задуматься о правильности, еще чаще страдал в последствии от принятого решения упростить разработку сейчас.

Что такое?

Технический долг — это разница между идеальным техническим решением и тем решением, которое принимается сейчас. Го́вард Ка́ннингем
Технический долг — это метафора, обозначающая плохую продуманность структуры системы, непродуманную архитектуру программного обеспечения или некачественную разработку ПО. Вики

Если проще — это осмысленное «забивание» на хорошее (в плане поддержки, читабельности, гибкости и пр.) решение в пользу получения краткосрочной выгоды.

Относиться к нему можно по разному (как наверно к обычным кредитам) — кто то берет на себя и не стесняется что придется отдавать с процентами, а кто то их намеренно сторонится и считает крайней мерой. Порой создание технического долга вполне оправдано, поскольку это единственная возможность существования продукта в принципе. Если говорить иначе — если не взять в долг и не выпустить продукт сейчас, то можно вообще его не выпускать.

Однако есть одна особенность у данного понятия. Осмысленное «костыльное» решение не означает, что мы должны распостранять его на всю систему и делать основополагающим. Как раз наоборот, это означает что нужно снизить возможные последствия, вынеся «костыль» в какую то абстракцию, которую можно будет быстро и безболезненно исправить, вырезать или переделать.

Источник долга

Фраза в начале статьи на самом деле есть вполне осмысленное решение взять на себя долг. Когда мы забиваем на техническое решение в угоду текущих выгод то просто откладываем решение этих проблем на потом. Такой долг можно назвать осознанным. Мы выигрываем время, но проигрываем в гибкости, сопровождаемости, может быть даже в скорости или стабильности, но можем выкатить функционал быстро и получить за счет этого преимущество в бизнесе. Может так случиться что этот долг вообще не придется выплачивать, например если функционал окажется невостребован и его просто «выпилят» из системы.

Другой тип долга в среде программистов прячется за термином «говнокод» Этот долг возникает неумышленно от неопытности программиста, от принятия неправильного решения в коде, конструкций языка, неправильного применения ООП, фреймворков и пр. Такой долг можно назвать неосознанным. Какими бы крутыми не были программисты он все равно появится. Лично я с натяжкой относил бы это к техническому долгу, все таки для меня, как программиста, это просто плохой код.

При использовании сторонних решения и библиотек мы как правило разрабатываем код, ориентируясь на определенную версию ПО. Визуальные компоненты, фреймворки, даже ОС. Если сидеть на одной версии достаточно долго то возникает технологический долг. Чем дольше тянуть с обновлением, тем более дорого оно обойдется (начислятся проценты).

Еще один источник долга это бизнес. Частое изменение, добавление требований это норма, и не только в enterprise. Под требования нужно менять архитектуру, а делается это как правило не быстро и далеко не бесплатно. Отсюда появляется архитектурный долг. Когда с коллегой обсуждали эту ситуацию, так и не пришли к единому мнению — считать ли «догоняющую» требования архитуктуру техническим долгом. Ведь с другой стороны это изменение требований. На мой взгляд нужно разделить эти понятия — изменение требований может привести к изменению кода. Менять код можно или с переделкой архитектуры (что дорого, долго и, как правило, бажно) либо засунув костыль. Именно второй подход в данном случае я бы отнес к техдолгу.

Почему может появиться технический долг

Я попытался организовать список по частоте и важности с моей точки зрения:

  • Негибкая архитектура. Отсутствие созданных слабо связанных компонентов. Когда программное обеспечение не является достаточно гибким, чтобы адаптироваться к изменениям бизнес-потребностей.
  • Поощрение быстрой разработки и рискованных исправлений («костылей»), чтобы исправить ошибки.
  • Отсутствие тестов.
  • Отложенный рефакторинг — пока создаются требования к проекту, может стать очевидным, что части кода стали громоздкими и должны быть переработаны в целях поддержки будущих требований. Чем дольше задерживается рефакторинг и чем больше написано кода, использующего текущее состояние проекта, тем больше накапливается долга, который должен будет быть оплачен в момент последующего рефакторинга.
  • Отсутствие знаний, когда разработчик просто не умеет писать качественный код.
  • Давление бизнеса. Нужно выпустить функционал как можно раньше.
  • Отсутствие у бизнеса понимания о технической задолженности и необходимости рефакторинга.
  • Отсутствие документации. Работа, необходимая для создания вспомогательной документации, — это также долг, который должен быть оплачен.
  • Отсутствие взаимодействия, когда база знаний не распространяется по организации и страдает эффективность бизнеса, или младшие разработчики неправильно обучены их наставниками.
  • Изолированная разработка в двух разных ветках при слиянии может породить код, который нужно будет перерабатывать.

Проценты

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

  • Затрагивание связанного кода может увеличивать и текущий технический долг.
  • Разработчики могут просто забывать для чего и как написан код.

Как выплачивать долг

Это пожалуй основной вопрос на котором я хотел бы остановиться и адресовать его своим читателям.

Реклама

WS-Trust. Ускоряем безопасный сервис до 20%

WCF Blog

При рассмотрении безопасности в WCF как правило делят ее на три составных части — конфеденциальность или шифрование, защиту целостности или подписание и аутентификацию. любой из этих механизмов можно обеспечивать на двух уровнях — на уровне транспорта и на уровне сообщения. Выбрать соответствующую модель безопасности можно в конфигурации:

<bindings><wsHttpBinding><binding><security mode="Transport"><transport/><message/></security></binding></wsHttpBinding></bindings>

Режимов может быть 4: None, Transport, Message, TransportWithMessageCredential. С первыми тремя как правило вопросов не возникает, а вот последний — штука интересная. Конфеденциальность и целостность обеспечивается за счет транспорта (обычный SSL), а аутентификация происходит на уровне сообщения.
Зачем нужен подобный режим? Транспорт ограничен в использовании механизмов аутентификации. Например тот же https может использовать basic, windows (ntlm или kerberos), digest, certificate. Если стандартный механизм не подходит (например, какая то…

View original post ещё 271 слово

WCF Blog

Исходная задача

Необходимо реализовать для WCF REST сервиса basic аутентификацию. Данные для проверки аутентификации необходимо делегировать стороннему MembershipProvider (то есть брать из сторонних источников, а не с контроллера домена).
Да, я знаю что basic аутентификация это не круто, не секьюрно и т.д. но это достаточно популярный и простой сценарий аутентификации и порой вполне применимый.

Проблема

Собственно включение basic аутентификации для REST сервиса задача тревиальная, нетривиально именно делегировать проверку данных своему (или стороннему коду). Почему так происходит? Дело в том, что при включении basic аутентификации в IIS, стандартный провайдер безопасности для basic аутентификации не делегирует проверки коду сайта, а осуществляет ее самостоятельно (с использованием, естественно виндовых пользователей) и только после удачной проверки делегирует вызов коду сайта/сервиса.

Решение

Есть два решения:

  1. Разработка своего провайдера basic аутентификации для IIS (где то находил и даже ставил подобную шутку).Плюсы: очень удобно, если бы был готовый удобный провайдер аутентифкации для IIS, но к сожалению я нашел…

View original post ещё 258 слов

VSLive 2012 Ижевск

Впечатления о выступлении остались только позитивные и надеюсь что доклад понравился.

Презентация, по которой делал доклад:

Виртуальная машина, на которой можно попробовать TFS 11 beta и VS 11 beta (на ней показывал демо):
http://blogs.msdn.com/b/briankel/archive/2011/09/16/visual-studio-11-application-lifecycle-management-virtual-machine-and-hands-on-labs-demo-scripts.aspx

TFS 11 как облачный сервис можно попробовать на ресурсе http://tfspreview.com/

Еще раз хочу сказать спасибо всем кто пришел, если на чьи то опросы не успел или не смог сразу ответить — я жду вопросы на почту, постараюсь ответить как можно быстрее.

Запись опубликована автором в рубрике IT.

Ускоряем .NET приложение

Напомню, что есть такая замечательная тулза, как ngen, которая умеет компилять из CLR кода машинный и помещает последний в кеш. За счет этого ускоряется работа приложения, потому JIT компиляции уже не происходит.

Сегодня оптимизировал MetroTwit, субъективно стал работать чуть быстрей. Так как сборок там куча, пришлось написать небольшой скрипт (себе, чтобы не забыть и не писать по 30 раз один и тот же и вам чтобы пользоваться):

for %%i in (*.dll) do ngen.exe %%i
for %%i in (*.exe) do ngen.exe %%i