2015-12-10: Технический долг - как работать с костылями

Материал из MaksWiki
Перейти к: навигация, поиск

Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костылями быстрее, чем без них". А кроме костылей есть еще много других способов сделать быстрее. Например, опустить документацию, не делать тесты, не реализовывать побочные ветви процесса, которые сейчас все равно не понадобятся. В результате вполне работающий софт может появиться гораздо быстрее, особенно у опытного разработчика. Проблемы вскрываются потом, когда этот код надо сопровождать, дорабатывать, рефакторить. Вот тут-то выясняется, что никто не знает, как этот код работает и как он должен работать, является ли какое-либо поведение фичей или багом. Даже сам автор. Даже если он доступен, через полгода-год работы на другом проекте подробности вытесняются из памяти.

Для работы с этим в отрасли придумано такая конструкция, как технический долг. И когда встрече по Agile для госпроектов в обсуждении в группах зашла речь об этих проблемах я бегло рассказал об этой практике. На уровне беглого рассказа это приняли, но потом некоторые участники у меня просили литературу, где бы это было описано подробнее. В литературе я не силен, поэтому переадресовал вопрос Алексею Пименову, но оказалось, что он тоже не знает хороших книг и смог вспомнить только доклад Антона Бевзюка на AgileDays-14 Эй, программистик, за тобой должок!

Я, в свою очередь, бегло посмотрел инет и тоже не нашел хороших материалов. В основном идут достаточно наивные рассуждения о том, что, дескать, глупые менеджеры не понимают высокие принципы технической эстетики, и потому надо переходить на их язык. Объяснить, что любой проект надо делать по-хорошему, а если он по каким-то соображениям делается не столь качественно, то, значит, это сделано не полностью, а с недоделками, эти недоделки, являются техническим долгом, их надо записывать и устранять. К сожалению, такие рассуждения плохо убеждают менеджеров,как и любые апелляции к чувству прекрасного. Особенно если безобразия и недостатки скрыты внутри, а снаружи все хорошо - софт-то работает.

Поэтому я и пишу данный пост.

[ Хронологический вид ]Комментарии

Мне кажется что на эту тему надо смотреть шире, а именно попытаться понять почему принимается решение о взятии долга. Результаты разбора (статья, доклады) и много интересных ссылок можно посмотреть тут http://www.maxshulga.ru/search/label/техдолг. В том числе есть мнение, что не надо тратить время на отслеживание долга: http://swreflections.blogspot.ru/2015/02/dont-waste-time-tracking-technical-debt.html

Максим, спасибо за ссылки. А по отслеживанию долга все просто: любая практика (code review, парное программирование и другие) может быть уместной и лишней в конкретном проекте. Для нее надо понимать - какие цели мы через нее достигаем, являются ли они существенными и нельзя ли их достичь через более легкие практики.

Ссылки на материалы с обсуждения на Facebook

  1. От Бориса Вольфсона - его доклад http://www.slideshare.net/blv/c-14782982 К сожалению, видео оказалось битым, только слайды.
  2. От Николая Рыжикова Материалы на InfoQ http://www.infoq.com/technicaldebt/ там много. Но я посмотрел несколько статей "подходящих" по названию - (Managing Technical Debt Using Total Cost of Ownership, Addressing Organizational Debt, How To Pay Down Technical Debt), к сожалению там в основном качественные рассуждения о том, что технический долг надо устранять, а то будут потери. Механизма расчета потерь нет. Если воспользоваться метафорой кредитной ставки в последней статье, там говорят "ну, вы же не будете пользоваться кредитной картой под 36%". На это есть два возражения менеджера (в метафоре): (а) а докажите, что там 36%, а не 12% и (б) многие люди используют кредиты типа "быстрые деньги" под 100 и более процентов.

Войдите, чтобы комментировать.