まだそういう問題に出くわしたことがないな。優先度は低いかもしれないけど、壊れた窓（『Pragmatic Programmer』の本）みたいなもんだよね。直さないタイプの問題なら、ソフトウェアのドキュメントに追加しとけばいいんじゃない？

Gitのコミットメッセージに入れちゃえばいいよ。ほとんどのコミットはあんまり良くないし。TODOで石器時代に戻るのではなく、もっと良いツールの使い方を促進したらどう？多くの人はあまり頻繁にコミットしないし、無関係な変更を絡めちゃうことが多い。最後に、コミットメッセージが「somefile.pyを更新しました」とか、似たような役に立たないものだったら最悪だよね。

大きなコードベースだと、いろんな人からのTODOがたくさんあって扱いにくくなるのは分かるけど、個人プロジェクトではいつも良い妥協だと思ってる。私にとっては、「うん、もっと良くできるのは分かってるけど、これで思考の流れを壊したくない」ってことなんだ。機能を壊すほどの重要性はないし、ただちょっと良くなればいいって感じ。たまに思いつきで何かに戻って、サクッと修正したいときにTODOのハイライトがエディタで役立つのは本当にありがたい。（でも、実際にはそんなに頻繁にあるわけじゃないし、大抵は無期限に放置されるけどね）

JIRA用のMCPサーバーがあって、AIがチケットを自動で記入してくれるんだよね、Cursorの中からそのまま。

重要なのは、時々コードに作業が必要だっていうサインが欲しいってことだよね。そういう場合、JIRAやGHのイシューで追跡しても、やっぱりリンクは必要だと思う。参照は継続性への賭けみたいなもので、コメントに説明がないと、いつかその意味を失っちゃうかもしれない。

コメントは通常、コードが何をしているのかを説明するためのものだよね。例えば「// ユーザーがこのボタンを3回クリックすると、クリックハンドラーがエラーになる [xyz]」って書いても、パッと見でこの挙動が望ましくないってのは分かりにくい。これはバグなのか、それともこういうもんなのか？「TODO」は、個人的には「ここは理想的じゃないから、コードに取り組むときは覚えておいた方がいいかも」っていう簡単なマーカーだと思ってる。もし君やレビュー担当者が、修正が実装されないのはダメだって分かってるなら、もちろん、ちゃんと実行される場所で追跡しておくべきだよ。私の経験では、TODOコメントを避けると、ドキュメントが少なくなって、コードが良くなるわけじゃないんだよね。

それはスキップだね。ほとんどは、やらなくても大丈夫。問題なのは、コードが完全に機能してないのに、そうだと思い込んでること。私のお気に入りのTODOは、クラスEncryptedSharedPreferencesに「TODO: これを暗号化する」っていうのがあった。私が入る前に書かれたもので（絶対に承認しなかっただろうけど笑）、このコードが実際に暗号化されてないってことが明確になってたから、他のモジュールで暗号化されてるかどうかを考えたり、二重に暗号化しちゃう心配をしなくて済んだ。

それは「良い」TODOコメントの例としては好きじゃないな。だって、そのコメントを書くのと同じ労力で問題を直せるか、少なくともエラーじゃない何かをさせることができるから（その後、「トリプルクリックは無視されます [xyz]」みたいなコメントを残すとか）。トリガーとエラーの理由を特定するためにすでに努力してるわけだから、たぶん80%はできてると思うよ。