Автор Патрик ДеВиво
Вы когда-нибудь сталкивались с комментарием TODO в каком-либо коде и хихикали? Возможно, это выглядело так: // TODO fix this
, без контекста. Возможно, он был добавлен много лет назад разработчиком, который покинул проект. Или еще лучше, может быть, вы добавили это сами и с тех пор ни о чем не задумывались.
Комментарии TODO - это простой способ сказать: «Хм, это не идеально, но я собираюсь двигаться дальше и, надеюсь, сделаю это лучше в будущем».
Они бывают разных форм: FIXME, HACK, OPTIMIZE, и они встроены в программные привычки достаточного количества разработчиков, поэтому многие IDE поставляются с предустановленной поддержкой для их поиска и отображения.
Как создатель tickgit, инструмента, который использует комментарии TODO, чтобы помочь разработчикам управлять проектами, я, безусловно, предвзято отношусь к общему использованию комментариев TODO, и я надеюсь, что на это есть веские причины.
Низкие накладные расходы
TODO легко добавлять и удалять. Они представляют собой открытый текст и, как таковые, довольно гибкие. Вы можете сделать ссылку на заявку, написать очень длинный комментарий, добавить немного ASCII-арта, использовать смайлы и т. Д. Иногда лучше меньше, да лучше, и открытый текст может иметь большое значение.
Нет переключения контекста
TODO прямо в вашем коде, рядом с тем, что они обычно описывают. Вам не нужно переключать контексты между вашей системой продажи билетов и кодом или переходить от одного к другому с помощью хлебных крошек. Если вы работаете над ходом мыслей в своем коде, комментарии должны помочь вам напомнить о том, над чем вы работаете - что нужно улучшить, что уже реализовано, что можно изменить или сделать лучше.
Иногда бывает трудно понять все это из внешнего тикета, и для этого может потребоваться полная копия контекста вашего кода в тикет. Более того, этот контекст может со временем измениться, и ваш билет может устареть.
Иметь историю
TODO могут быть зарегистрированы в вашей VCS и, как таковые, иметь историю. Их можно обвинить, пересмотреть код и рассматривать как любую другую строку кода или комментарий в вашем проекте.
Четыре года назад такой-то и такой-то ушел из
# OPIMIZE we can speed this up by doing …
, и теперь, когда мы достигли определенного масштаба, самое время для реализации. Хорошо, что она оставила записки!
CI/CD
Поскольку они являются частью вашего исходного кода, вы можете точно так же применять к ним инструменты CI / CD. Фактически, существующие инструменты уже делают это. Не хотите использовать TODO в master
? Хотите убедиться, что они следуют формату? (т. е. иметь правопреемника - // HACK (patrickdevivo)
) Может быть, не удастся CI, если они были в коде более X дней? Это, конечно, зависит от вас и предпочтений вашего проекта.
Можно использовать как угодно
Из-за их простоты, гибкости и эквивалентности комментариям к коду у вас есть большая свобода с TODO и «правилами» вокруг них. Это может проявляться в привычках или полномасштабных политиках и процедурах, применяемых через CI.
Даже профессионалы используют их
Некоторые большие проекты используют их по-разному, с разной степенью строгости. Некоторые требуют, чтобы каждое TODO было привязано к заявке с уполномоченным / контактным лицом.
Так в чем же шутка?
Шутка в том, что многие комментарии TODO забыты. Их отбрасывают из-за нарушения сроков, смещения приоритетов, смещения контекста и всех других недугов, которые могут подорвать команду инженеров.
Просто посмотрите на средний возраст многих TODO по ссылкам выше. Если кто-то оставляет записку, и она остается нетронутой в течение многих лет, стоит ли вообще что-то говорить? Как мы можем лучше управлять TODO? Стоит ли нам вообще беспокоиться?
(это та часть, куда я бессовестно подключаю свой проект)
Я надеюсь, что с помощью такого инструмента и сервиса, как tickgit.com, мы сможем лучше справиться с постоянно движущейся природой нашего кода. Более совершенные инструменты могут раскрыть передовой опыт и, будем надеяться, лучшую разработку программного обеспечения. Независимо от того, как вы используете комментарии TODO, я надеюсь, что вы найдете ценность в использовании чего-то вроде tickgit, чтобы проактивно отображать их и следить за своим техническим долгом. Иногда немного UX и DX может иметь огромное влияние, и я хотел бы превратить этот проект в эффективный инструмент, который поможет нам всем поддерживать лучший код. Поэтому, пожалуйста, протяните руку, если это находит отклик у вас, если у вас есть предложения или по любой другой причине!
Но // TODO - это запах кода!
ИМО, TODO инертны. Это инструмент, который можно использовать как эффективно, так и нет. Если вы считаете их плохой практикой, я бы посоветовал рассмотреть то, что вы считаете «плохим» - сам TODO или то, как они используются (или нет)?
А если это запах кода, может быть, поможет интеграция с политикой и CI?
P.S.
Посетите imdone.io, чтобы увидеть еще один интересный проект, помогающий разработчикам управлять проектами с помощью TODO.