Pull to refresh

Comments 8

Нет ничего более постоянного, чем временное!

Так всегда было, todo весят годами и никто не трогает, пока не завоняет)

Согласен. У TODO нет дедлайна и владельца - поэтому он и тухнет. Тикет в бэклоге хотя бы попадает в обсуждение на груминге, и его кто-то да заденет

В памяти в е не удержишь , сразу весь код не напишешь , а если несколько человек над проектом работает так это еще в разы усложняет понимание кода , вот так хвосты и вылазят

Так и есть. Поэтому, на мой взгляд, ставка должна быть не "помнить", а на инструменты, которые напомнят сами: метрики на deprecated-эндпоинты, алерты на размер ответа/heap, lint на отсутствие LIMIT в запросах. Память - плохой бэкап для tech-debt, особенно в команде

Возможно, проблема не в том, что "никто не завёл тикет", а в том, что TODO-комментарий и тикет в бэклоге – разные категории видимости. TODO виден только тому, кто открыл файл; тикет виден всей команде при планировании. Разделение tech-debt на "задокументированный в коде" и "зафиксированный в системе" – это не бюрократия, а управление риском.

Полностью согласен, это ,по-моему, главная мысль из всей истории. TODO это приватная заметка для того, кто открыл файл; тикет это публичное обязательство команды. Они решают разные задачи и не заменяют друг друга

Я бы ещё добавил третий уровень - runtime-видимость: метрика/алерт на сам артефакт (вызовы deprecated-эндпоинта, размер ответа, время выполнения и тд и тд. Тикет говорит "мы знаем, что это надо починить", метрика говорит "вот сейчас оно начинает болеть". Без третьего уровня тикет может так же тихо висеть в бэклоге, как TODO в коде

Разделение tech-debt на "задокументированный в коде" 

Ты это как предлагаешь отслеживать в динамике?

Sign up to leave a comment.

Articles