Для нетерпеливых: на TODO всем пофиг
Ситуация до боли всем знакомая: делаем новую фичу, торопимся, узнаем какую-то особенность, которую по какой-то причине нужно сделать, например: обработать ошибку, которая может появиться в 1 случае на 1 000 000. Пишем для себя будущего TODO:
TODO: Обработать ошибку, иначе заказ сломается, если в корзине будет 11 хотдогов
Но в ходе работы будут появляться более важные задачи, которые задвинут исправление этой досадной ошибки в долгий ящик.
Потом со временем таких пометок в проекте будет много, большинство из них отпразднуют свой день рождения, а может и не один.
Проект, который зарос TODO (33 TODO это конечно немного, но когда начинаешь их разбирать и исправлять, то процесс может затянуться на недели)
Мой опыт в профессии показывает, что чем старше TODO, тем меньше вероятность, что его выполнят, и на это есть свои причины:
- Так уже несколько лет работает, не трогай — сломаешь;
- TODO плохо описана, и суть проблемы уже никому не ясна;
- В проекте так много TODO, что их уже просто игнорируют;
- На исправление тех. долга бизнес не выделяет ресурсы.
У TODO описанных в коде есть еще одна важная и неприятная особенность: про них не знает бизнес, а значит ему неизвестна проблема, которая возникла и к чему она может привести.
На самом деле решение банальное и простое. В трекере задач нужно завести соответствующий таск, в котором описывается: проблема, решение и дается оценка по трудозатратам.
При таком подходе в коде не нужны TODO, а список технического долга наконец-то доступен: бизнесу (в таком случае задача может быть поднята в приоритете, если риск поломки высок), разработчикам, мозолит глаза всем и каждому.
C точки зрения кодовой базы и организации работы с тех. долгом, считаю идеальным тот проект, в котором настроен линтер на недопущение TODO комментариев, а задачи на доработку тех или иных моментов оформлены в трекере задач с детальным описанием проблемы и решения.
Анализатор кода, настроенный на запрет TODO