Звездолеты на ДВС. Выжить в схватке с техническим долгом

[amarao]

Мой опыт работы с бэклогом технического долга как самостоятельной сущностью.

Август 1000 года.

• Программист дописывает в код, который обслуживал одну сущность, поддержку нескольких независимых сущностей (федерацию, домены, namespace'ы, you name it). Он обнаруживает, что в коде есть неявная зависимость от синглтона (самого синглтона нет, но в процессе исполнения система ведёт себя так, что есть единая state-machine, которая позволяла очень эффективно обрабатывать одну сущность). Т.к. федеративность подгорала, то проблему решили добавив в код поддержку списка сущностей в каждом месте, где есть использование этого неявного синглтона. Получилось очень некрасиво и тимлид настаивал, что надо вынести этот "синглтон" в отдельную сущность, способную обслуживать состояния нескольких объектов. Но это потребовало бы а) времени б) изменений в системе визуализации прогресса, которая подглядывала за синглтоном. Задачу записали как техдолг и move on.

Сентябрь 1002 года. У программистов квота 10% времени и на совещании о том, что делать, обсуждают эту задачу: а) тимлид уже уволился. б) никто не понимает о каком синглтоне идёт речь потому что слово singleton в коде нет и глобальных перменных нет в) федеративность уже давно стала иерархической с наследуемыми распределяемыми квотами, так что старая идея не работает г) никто не хочет нырять в это г, потому что оно выглядит как спагетти-монстр.

Чем более формализованным является управление техдолгом, тем более абсурдным техдолг выглядит.

[ReppDen]

Хах, забавно и достаточно жизненно.
Как я и указал в статье, выделенные 10% позволят лишь разобраться с долгом, который мы только что создали и не раздувать технический бэклог. Опыт показывает, что техническому долгу, забытому на несколько лет, поможет только огнемет.

[Kwisatz]

Приятная статья, но знали бы вы на какую мозоль наступили. Я регулярно встречаю проекты состоящие из легаси на 110% (10% это костыли которые постоянно дописываются чтобы оно работало). Проблема в том, что тут кроме «переписать все с нуля» рецепта нет и все мы знаем, что анализ легаси невероятно дорог, а убедить строить новую систему на нуждах бизнеса а не на легаси бывает довольно сложно.

Все мы так же стараемся избегать молодежного подхода «грохнуть все», но когда при реализации новых фич затраты R&D превышают затраты на разработку, какие уже могут быть варианты?

[ReppDen]

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

[Kwisatz]

Бизнес традиционно хочет денег и чтобы основные каналы их поступления работали без перебоев. Вот только часто возникает ситуация, когда обслуживание технического долга требует запредельных ресурсов. В такой ситуации эти куски могут быть размером со всю систему.

Можно и пообщаться, с умными людьми всегда интересно поговорить.

[nApoBo3]

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

Если у нас все так, мы и так не будем иметь значительных проблем с тех.долгом. Что-то типа как мотивировать само мотивированных, или обучать обучаемых.

[korsarer]

Перевожу с хипстерского на русский. Слово «кейс» в данном случае это слово «case» — в переводе с английского: «случай», а также в переводе с английского: «дело, ящик, футляр, падеж, сумка, коробка, доводы». Почему-то некоторые Хабравчане и другие пользователи интернета решили, что использовать слово «кейсы» круто и что это гораздо удобнее, чем слово «случаи».
Так что в следующий раз, вместо «Именительный падеж» говорите «Именительный кейс», а вместо «Приведите свои доводы» говорите «Приведите свои кейсы»(sarcasm).