プルリクエストでTODOを処理する方法

プルリクエストの変更を確認すると、「TODO」のメモが付いたコメントに出くわすことがあります。

• 問題を解決するために使用されるソリューションは改善できますが、かなりの時間投資が必要になります。作成者はより迅速なソリューションを選択しましたが、より良いオプションが潜在的に利用可能であるというコメントを入れました
• すぐに修正する必要がある既存のバグを回避するための一時的なコードがあります

TODOsが一般的にコードベースの存続期間中コードベースに留まることを知っているので、プルリクエストでそれらにどのように対応する必要がありますか？どうすればそれを避けるよう丁寧に要求できますか、またはそれが本当に正当化された場合、PRの作者が将来それをフォローアップすることをどのように確認できますか？

チーム/部門/組織内で「一般にコードベースの存続期間中、コードベースに留まる」と言うときは、次のことを考慮してください。

• あなたにそれを書き留め国防総省TODO、FIXME同様のタグは避けるべきである、または。
• SonarQubeなどの静的コード分析ツールを使用して、ビルドを自動的に不安定としてマークします。
• 問題トラッカーに対応するチケットがある場合にのみ、一時的にそれらを許可します。次に、コードは次のようになりますTODO [ID-123] Description ...

私のコメントで述べたように、最後のステートメントはおそらく、チケットが腐敗しない環境でのみ意味があります（たとえば、バグがゼロのポリシーに従っている場合）。

個人的には、TODOsが妥当な場合もあると思いますが、過度に使用すべきではありません。Robert C. Martinの「Clean Code：A Handbook of Agile Software Craftsmanship」（p。59）から引用：

TODOsはプログラマーがやるべきだと思う仕事ですが、何らかの理由で現時点ではできません。廃止された機能を削除することを思い出させるか、他の誰かが問題を見るように懇願するかもしれません。他の誰かがより良い名前を考えたり、予定されているイベントに依存する変更を行うことを思い出させるためのリクエストかもしれません。他にどんなTODOことがあっても、システムに悪いコードを残すことは言い訳にはなりません。

TODOの彼ら自身は悪ではありません。私は、1層以上深くなることは決してなく、トラッカーチケットごとに常に1つの問題を修正することの大ファンです。

私はよく、TODOまたはFIXMEを使用して、問題を解決するために必要な、または戻って来たいと自分に思い出させます。

たとえば、add（a、b）を呼び出してTODOを追加し、addメソッドをリファクタリングできます。今はaddメソッドに取り組みたくありませんが、戻ってきたいです。

したがって、プルリクエストではTODOまたはFIXMEが表示されます。たとえば、FIXMEを使用して、他の開発者にコードの領域について責任を負わせ、混乱してはならないことを警告します。たとえば、FIXME addは負の数を受け入れることができません。

それらが見られない、または無視されるという問題を回避するために、私はすべてのTODO FIXMEおよびDEGUG行をリストするスクリプトを使用します。そして、それはコミットメッセージに追加されます。

すべてTODOである400行のコミットメッセージを無視するのは困難です。したがって、問題のコードにすでに触れている間、または新しいチケットを作成して問題コードをスタンドアロンで修正することで、人々はそれらを修正します。

公平を期すために、すべてのプロジェクトにコードのクリーンアップ時間を組み込むようにします。はい、beは15日に起動する準備ができていますが、15日から30日にコードをクリーンアップしていました。（奇妙に思えますが、製品を管理したことがある場合は、起動前に低視認性のタスクを実行しようとすると、それらにアクセスすることはできません。他の何かが優先されます。）

完全ではないプルリクエストが発生することがあります。現在、私は利用可能な時間内に「十分に」行うことができるが、完璧ではないいくつかの仕事をしています。そこで、プルリクエストを送信し、コメント付きのTODOをコードの適切な場所に配置すると同時に、別の変更リクエストを追加して、「十分」から「完璧」に変更します。

この新しい変更要求は優先順位を付けることができ、最も優先度の高いアイテムである場合に処理されます。今すぐ完璧にする必要があると判断された場合は、次に手渡されます。

あなたの質問：「どうすればそれを避けるよう丁寧に要求できますか、またはそれが本当に正当化された場合、どうすればPRの作者が将来それをフォローアップすることを確認できますか？」私が説明したことでは、それはかなり無難なようです。遅く出荷するか、十分に良いものを出荷するかの選択がある場合、それはあなたの決断ではありません。必要に応じてプロダクトマネージャーに問い合わせることができます。そして「PRの作者がフォローアップすることを確認してください」？あなたがチームを持っている場合は、これはあなたのシステムにログインしていることを確認する必要があり、うまくいけばあなたのチームは十分に記録され、物事が迷子にしないことに編成され、誰かが何の優先度の高い項目がない場合、最終的にそれを修正します。覚えておいて、それはチームの努力です。

プロジェクトがソースコード内の保留中のアイテムをTODOコメント付きで追跡する場合は、許可する必要があります。

TODOプルリクエストにコメントが存在することでバグが発生しているという事実は、ソースコードで保留中のアイテムを追跡するのは悪い考えであることを伝える必要があります。物事はそのように失われたり、無視される傾向があります。さて、 "working fork"へのプルリクエストについて話している場合、状況は異なります。「作業フォーク」とは、まさにそれであり、進行中の作業です。しかし、そのようなフォークは通常プル要求を必要としません。ここで提案する「ハウスルール」は、マスターブランチのプルリクエスト用です。

ハウスルール＃1 -へのすべてのコミットマスターがいるので、テストのために準備する必要がありますマスターは任意のチェックイン後に毎日構築されています。これらのコミットには、必要な追加テストも含める必要があります。

TODOコードが終了していないか、テストが終了していないか、コードがテストの準備ができていないためにコメントがある場合、そのコードはプルリクエストではなくローカルコミットに属します。準備ができたら電話してください。

ハウスルール＃2-未解決の問題に関するすべての情報は問題トラッカーに保存されます。それのすべて。ノート、落書き、ハンチなど。

場合はTODO、コメント未解決の問題に関連し、かつ、その問題に対する実際の修正はありませんが、その情報は、問題追跡に属します。これにより、問題が解決する前に、必要に応じてすべての情報を確認および検証して、問題が実際に解決されていることを確認できます。

ハウスルール＃3-保留中のプロジェクトタスクに関するすべての情報は、優先度キュー（またはシステムの名前）に属します。

明確にするために、保留中のプロジェクトタスクは、課題チケットを生成する前に発見された欠陥であるか、特定の設計要件の実装であるか、またはその要件に必要なコンポーネント。

TODO新しいコードが保留中のタスクに影響を与えるというコメントがある場合、または新しいコードを実装するときに発見されたコードベース内の他の何かを指摘する場合、その情報は次のいずれかの優先度キューに属します既存のタスクとして、または新しいタスクとして。

ハウスルール＃4-提案はアイデアボックス（またはその他）に属します。

TODOコメントがソフトウェアの設計または実装の変更を示唆している場合、その情報はプロジェクトのアイデアボックス、または「vNext」、「Design Notes」、またはそのようなものにあるものに属します。

ハウスルール＃5- TODOソースコードではコメントは許可されていません。期間。

このルールを守れば、誰かが何かをフォローアップすることを心配する必要はありません。