コードレビューに送信されるコードコメントのメモ/やることは、効果的なリファクタリングプロセスにつながる可能性がありますか？
私の会社で、地理的に分散したレベルで、集合的なコード所有権の文化を開始/改善したいと思います...現在、集合的なコード所有権の考え方がいくつかありますが、それは単一の地理的なサイトだけです。
これはこの質問のフォローアップです： 他のコードをリファクタリングする政治的に正しい方法は何ですか？
コードレビュー（ReviewBoardがあり、Crucibleにアップグレードする可能性があります）に*コードコメントだけ*を送信することが実際に効果的なメカニズムになるかどうか疑問に思っています他の人に自分のコードについて領土を感じさせることなく、コードの改善について会話を始めましょう。
たとえば、次のように追加します。
//ToDo: Refactor this code and that code because of reasons X and Y
次に、コードレビューのために送信すると、承認されます...合意と見なすことができます（新しいコードを前もって取得するのが難しい場合があると思います）。同時に、作成者（および他の人）は、提案を消化して受け入れるのが簡単な場合があります。物事を壊す可能性があるという理由で提案を拒否することはもはや正当な理由ではなく、したがって変更を加えることへの恐れが失われます...同時に、誰もそれが価値があるとは思わないものを最適化するために10時間を投資しないでください恐れからそれに反対します。
これはすべて推測ですが、私はこのようなもの（コードレビュープロセスでコードコメントにリファクタリングノートを送信する）が機能すると感じています。 誰かが実際にこのようなことをしたことがありますか？もしそうなら、結果はどうでしたか？
正式なレビュープロセスを使用する
これが実際にすべてのメンバーが従う必要のあるプロセスの一部である場合、それは機能します。
つまり、コードレビューが開始されると、コメントがあることが予想され、これらのコメントについて話し合って破棄するか、変更を実装することによって、これらのコメントに対処する必要があります。
フォローアップアクションのための問題追跡システムへのリンク
非常に正式なものにしたい場合（環境や監査手順によっては必要になる場合があります）、必要なアクションごとにトラッカーで新しいチケットを開くこともできます。チケットは、修正されたものとして閉じるか、必要なコメントを付けて拒否することができます。明確化。さらにレビューが必要な場合は、レビューリクエストを開きます（そうするためのツールがあると仮定します）。コードの変更は、できれば元のレビュー担当者が確認する必要があります。
コードベースを壊すことに注意してください
それがプロセスの一部でない場合、そのようなコメントはデッドコードやコード腐敗に似たものになる可能性が高く、回答よりも多くの質問が残る可能性があります。したがって、正式なレビュープロセスがない場合は、個人的な追跡用であり、それらを厳重に監視している場合を除いて、それらを避けたいと思うかもしれません。これらは、できれば寿命が短く、迅速に対応する必要があります。または、TODOであってはならず、何が問題であるかについての実際のコードコメントであり、大きな変更である場合は、他の開発者への警告として機能するように変更する必要があります。
私は（一般的な場合）インラインアクションタグと役に立たないインラインコメントに対して追加の理由を与えます answer非文書化インラインコメントの使用 について。
実際、適切なツールを使用できる場合は、コードレビューではこれらを避け、コードからこれを分離できるコードレビューおよびコード注釈ツールを使用することをお勧めします。
コードレビューとコード注釈ツールに依存する
SCMにコードをすべて含めたい場合があるため、決定するのは難しいです（実際、レビューコメントをソースファイルと一緒にテキストファイルに保存するEclipse用のコードレビューツールもあります）。ただし、大規模なチームやプロジェクトの場合は、コードに注釈を付けるための専用ツールを用意し、コードのコンテキスト内のどこかに詳細なディスカッションを記録しておくと非常に効果的です。また、それらを現在のコードレビューやタスクにリンクしたり、ファイルや変更セットに直接コメントしたりすることもできます。
たとえば、上のスクリーンショットでは、懸念事項を強調するためにコードが直接インライン化されたスレッドディスカッションを見ることができます。これは、正式なコアレビューアイテムの一部として行われています（IDを使用） CR-ANERDS-8）オープンチケットに関連する（ID ANERDS-7）。
これは、レビューに対する今後のフォローアップアクションを追跡できるように新しいチケットを作成するユースケースの例です。レビュー担当者は、コードをふるいにかけて日陰に気付くと、簡単にタスクを作成できます。
これには多くのツールがありますが、個人的には、FishEyeとCrucibleが標準を上回っています（そして明らかにJIRAと連携して、または必要に応じてさらに詳細なドキュメントにリンクするためにConfluenceでさえもうまく機能しています）。
私の経験では、誰もこれらのコメントを真剣に受け止めていないため、これは機能しません。 「TODO：このできるだけ早く取り除く」を見て、svnのせいにして、コメントが10年近く続いていることに気づくことほど面白いことはありません。
あなたが本当にする必要があるのは、実際の開発者の時間がリファクタリングに費やされていること、そしてリファクタリングタスクが明確に定義されていることを確認することです（制限はありません）。これをマネージャーに提示し、問題とそれを行うことのビジネス上の利点の概要を説明する必要があります。
例：「機能XとYの実装ははるかに簡単になり、最初にZをリファクタリングする場合ははるかに短い時間で済みます。Zをリファクタリングする時間を作ってみましょう！」
これは私には文化的な問題のように思われるので、文化に取り組むことをお勧めします。あなたの質問への間接的な答えとして、私はテクニカルブッククラブを始めることによって、集合的なコード所有権とリファクタリングプロセスのこのトピックを紹介することに成功しました。
クリーンコード ボブマーチンと レガシーコードで効果的に作業する マイケルフェザーズはこれらのトピックをうまく探求しています。
私は、コメントだけでは何も変わらないことを経験しました。プログラマーがまったく話さない場合（コードの解説を除いて）、何かがおかしいです。 // Todoを追加するだけでは問題は解決せず、さらに悪化する可能性があります。たとえば、誰かが気分を害した場合。
リファクタリングする価値のあるものを見つけた場合（そして、コードの一部を完全に理解していると確信している場合[〜＃〜] and [〜＃〜]既存のプログラムへの影響を実行してください。コードを完全に理解していないと思われる場合（これが最初にリファクタリングしたい理由かもしれません）、最初の開発者と連絡を取ってみてください。プロセスに彼を参加させ、何ができるかを話し合ってください。 、そして私は彼がリファクタリングの全プロセスを通して貴重なパートナーになると確信しています。