Автор Патрик ДеВиво

Вы когда-нибудь сталкивались с комментарием 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.