comments - コメント付きペアプログラミング

Question

何年にもわたって、グリーンプログラマーは問題をデバッグするためにコードではなくコメントを読む傾向があることを発見しました。

コード作成者の承認を得て、ある人が他の人のコードを文書化すること (およびその逆) は、長期的にコードの品質を向上させますか?

これは良い考えですか？

余談ですが、予算に関しては、ソロ プログラミングとペア プログラミングの中間点を探しています。

Answer 1

人は問題に対して最も簡単な解決策を探す傾向があります。「人間による」記述が利用可能であれば、読者が難解なコードを掘り下げる前に利用される可能性があります。IOW、プログラマーがたまたまどれほどグリーンであるかに関係なく、コメントが最初に考慮されることがよくあります。

コメントは可能な限り維持する必要があります。残念ながら、それらは簡単に古くなる可能性があります (コンパイラによって検証できないため)。したがって、最終的には、コード自体が信頼できる唯一の実際のコメントであるため、妥当な最小値に保つ必要があります。

誰がコメントを書くべきかについては、コメントがどのレベルで書かれているかによって異なります。たとえば、より高いレベルでは、コメントはモジュールの外部の動作を説明する必要があり、より大きなグループの人々によって記述される可能性があります。ただし、内部的には、コメントはコードのさまざまなチャンクの意図を説明する必要があります。そうすれば、読者はコードの癖を簡単に収集できます。これらのコメントはコーダーによって書かれるべきです。

Answer 2

「ペア プログラミング」は、1 人がコードを書き、もう 1 人が単体テストを作成する場合に最も効果的であることがわかりました (お互いが何をしているかを確認できるように並んで作業します)。時々役割を入れ替えることもできます。

Answer 3

元の作成者がコードを文書化していない場合、アルゴリズムを誤解するリスクが高くなります。私の意見では、不適切に文書化されたコードよりもイライラする唯一のものは、不適切に文書化されたコードです。

このアプローチを試してみてください:

• プログラミング作業に関与していない開発者と一緒にコード レビューを実行します。
• コードの作成者が実際に立ち会わずにレビューを実行します。レビュアー、ソース管理からのコードのコピー、および書面によるドキュメントのみ。
• レビュアーが外部の支援なしにコードを合理的に理解できない場合、それは適切に文書化されておらず、作成者に返されるべきです。
• 必要に応じて繰り返します。

Answer 4

ヘルパーが広い範囲の思考 (つまり、何を達成しようとしているのか) を行い、キーボード カウボーイが詳細な範囲の思考を行う場合に最も効果的だと思います。コメントは関係ないと思います。

Answer 5

私は、最初にコメントを書き、その直後にコードを書くか、時々または時々並べて書く傾向があります。コメントを書き終える頃には、コードが頭の中で非常に明確になっています (コメントを書きながら自分の考えを言語化したおかげです)。私が書いていないコードにコメントするのは好きではありません。そして、コードを修正するために戻ってくるときはいつでも、最初に元のコメントを読み、次に新しいコメントを考え、それらを書き、コードを並べて書きます。