プルリクエストでTODOを処理する方法
プルリクエストの変更を確認すると、「TODO」というコメントが付いたコメントに出くわすことがあります。これは、さまざまな理由で表示されることがあります。
- 問題の解決に使用されるソリューションは改善できますが、かなり多くの時間を投資する必要があります。作成者はより迅速な解決策を選択しましたが、より良いオプションが潜在的に利用可能であるとコメントしました
- すぐに修正する必要がある既存のバグを回避するための一時的なコードがあります
TODOsは通常、コードベースの存続期間中コードベースに留まることを知っているので、プルリクエストでそれらにどのように対応すればよいですか？どうすればそれを回避するように丁寧に要求できますか、またはそれが本当に正当である場合、PRの作成者が将来的にそれを確実にフォローできるようにするにはどうすればよいですか？
チーム/部門/組織で「コードベースの存続期間中、通常はコードベースにとどまる」と言うときは、次のことを考慮してください。
- DoD に書き留めます。
TODO、FIXME、または同様のタグは避けてください。 - SonarQube などの静的コード分析ツールを使用して、ビルドを自動的に不安定にマークします。
- 課題トラッカーに対応するチケットがある場合に限り、一時的にそれらを許可します。この場合、コードは
TODO [ID-123] Description ...のようになります。
私の comment で述べたように、最後のステートメントはおそらくチケットをローテーションさせない環境でのみ意味があります（たとえば zero-bugポリシー に従う場合）。
個人的には、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行のコミットメッセージを無視するのは困難です。そのため、問題のコードにすでに触れている間、または新しいチケットを作成して問題のあるコードをスタンドアロンで修正することにより、人々はそれらを修正します。
公平を期すために、すべてのプロジェクトに組み込みのコードのクリーンアップ時間があることも確認します。はい、15日にリリースする準備ができていますが、15から30までコードのクリーンアップを行っていました。 （奇妙に思われるかもしれませんが、製品を管理したことがある場合、起動前に可視性の低いタスクを実行しようとすると、それらに到達することは決してできなくなります。他の何かが優先されます。）
プロジェクトがTODOコメントを付けて保留中のアイテムをソースコードで追跡する場合は、許可する必要があります。
プルリクエスト内のTODOコメントの存在がバグであるという事実は、ソースコードで保留中のアイテムを追跡することは悪い考えであることを伝える必要があります。物事はそのように失われるか、無視される傾向があります。さて、もしあなたが「ワーキングフォーク」へのプルリクエストについて話しているなら、状況は異なります。 「ワーキングフォーク」とはまさにそれであり、進行中の作業です。しかし、そのようなフォークは通常プルリクエストを必要としません。ここで提案されている「ハウスルール」はmasterブランチのプルリクエスト用です。
House Rule＃1-masterはチェックイン後に毎日作成されるため、masterへのすべてのコミットはテストの準備ができているはずです。これらのコミットには、必要な追加のテストも含まれている必要があります。
コードが完了していない、またはテストが完了していない、またはコードがテストの準備ができていないためにTODOコメントが存在する場合、そのコードはローカルコミットに属し、プルリクエスト。準備ができたら電話してください。
ハウスルール＃2-未解決の問題に関するすべての情報は、問題トラッカーに保存されます。それのすべて。ノート、落書き、直感、なんでも。
TODOコメントが未解決の問題に関連し、その問題に対する実際の修正ではない場合、その情報は問題追跡に含まれます。これにより、問題が解決する前に、必要に応じてすべての情報を確認および検証して、問題が実際に解決されていることを確認できます。
ハウスルール＃3-保留中のプロジェクトタスクに関するすべての情報は、優先度キュー（またはシステムの名前であれば何でも）に属します。
明確にするために、保留中のプロジェクトタスクは、問題チケットを生成する前に発見された欠陥、特定の設計要件の実装、あるいはその要件に必要なコンポーネント。
TODOコメントがあり、新しいコードが保留中のタスクに影響を与える、または新しいコードを実装するときに発見された、コードベース内で確認する必要がある何かを指摘する場合、その情報は既存のタスクまたは新しいタスクとしての優先キュー。
ハウスルール＃4-提案はアイデアボックス（またはその他）に属します。
TODOコメントがソフトウェアの設計または実装の変更を示唆している場合、その情報はプロジェクトのアイデアボックス、「vNext」、または「デザインノート」、またはそのようなものに含まれています事の。
ハウスルール＃5-TODOコメントはソースコードでは使用できません。限目。
このルールに固執すれば、誰かが何かをフォローアップすることを心配する必要はありません。
完全ではないプルリクエストがある場合があります。現在、私は利用可能な時間内に「十分に」実行できるが、完全ではないいくつかの作業を行っています。そこでプルリクエストを送信し、コードの適切な場所にコメント付きのTODOを配置すると同時に、別の変更リクエストを追加して、「十分」から「完全」に変更します。
次に、この新しい変更要求に優先順位を付けることができ、それが最も優先度の高いアイテムであるときに処理されます。完璧である必要があると判断された場合現在は、次に渡されるものになります。
あなたの質問：「どうすればそれを回避するように丁寧に要求できますか、またはそれが本当に正当である場合、PRの作成者が将来的にそれをフォローするようにするにはどうすればよいですか？」私が説明しているように、それはかなり途方もないようです。配送を遅くするか、十分なものを配送するかを選択できる場合、それはあなたの決定ではありません。必要に応じて、製品マネージャーに問い合わせることができます。そして「PRの作者がそれをフォローアップすることを確認してください」？チームがある場合は、これがシステムに記録されていることを確認する必要があります。うまくいけば、記録されたものが失われないようにチームが十分に組織化されており、someoneが最終的にそれを修正します優先度の高いアイテムはありません。覚えておいてください、それはチームの努力です。