コードレビュー、利点は何ですか？[閉まっている]

私のチームでは、正式なコードレビューは行いません。ペアプログラミングと回転ペアで十分であると考える傾向があります。

正式なコードレビューを検討する必要がありますか？利点は何でしょうか？

コードレビューは少し異なります（おそらく）。

毎週金曜日にすべてのプログラマを集めて、1週間で何をしたかを確認します。次に、すべての完了/進行中のプロジェクトに少なくとも1人または数人の人がいるように、レビューするプロジェクトを選択しました。その後、1時間ほどで、行われた変更を確認し、ミスを検索し、他のプロジェクトがどのように機能するかなどを確認します。 FIXMEでコードをスパムします）。全体として、通常、私たち（10人のプログラマー）には約2時間かかります。

長所：

• すべてのメンバーは会社で何が起こるかを知っています
• バグがより早く発見される
• 読み取り可能なコード（説明や紹介なしで読み取れるコード！）
• 最適化手法/トリック/生産的プログラムの普及が加速
• スペシャリストとしてのプログラマーはより速く「進化」する
• 楽しいです

前述のペアプログラミングに反対しているのは（個人的な意見にすぎないことを確認してください）、チームが長く協力すればするほど速くなるということです。

私はそれが思考の糧をもたらすことを願っています。幸運を。

この無料の本を読みたいと思うかもしれません：

http://smartbear.com/best-kept-secrets-of-peer-code-review/

もちろん、彼らはプッシュする製品を持っていますが、そこにはまだ多くの有用な情報があります。

また、ペアプログラミングがどのように同じ利点を提供するかについても説明します。したがって、ペアプログラミングの場合は、コードのレビューはまったく必要ないかもしれません。

私はあなたの環境でレビューするのにあまり経験がありません。ここでは多くのペアプログラミングを行いません。チーム内でソフトウェアの知識を広めるためにコードレビューを行い、ミスを見つけ出すためにもう1組の目を持ち、ソフトウェアがコーディングガイドラインに準拠しているかどうかを確認する正式なポイントを持っています。

最初の2つのポイントはペアプログラミングで十分にカバーされています。3番目のポイントはペアに非常に依存しており、正式なコードレビューから改善できます。

正式なコードレビューを行う必要がありますか？

絶対に

だけで簡単にサイドノートとして、私が持っている非常にペアプログラミングを少し経験を、私はレビューは、これらのメソッドと競合するだろうと信じていません。

2つの形式のコードレビューを紹介します。

ピアコードレビュー

ペアプログラミングが機能する場合でも、コードに別の目を向けることは問題ありません。これには次の利点があります。

1. それはコードに新鮮な目を向けます。コードベースの領域について、あなた（および/またはあなたのパートナー）があまり知らないかもしれないより詳しい知識を持っている人。これにより、ノックオンの問題が明らかになる可能性があります。
2. これにより、（ペア）提出前にソリューションを再検証できます。レビューアはあなたが書いたものについて何も知らないので、あなたはそれ全体を説明しなければなりません。これにより、考えもしなかったエッジケースや無効なロジックが明らかになる可能性があります。

（私の世界では）ピアコードレビューは、すべての提出の前に行われます。ペアのプログラミングの世界でこれがどのように引き継がれるのか、私にはわかりません。

グループコードレビュー

これらはピアコードレビューよりも頻繁に発生しません。私は通常、非公式のコードレビューのために、会議室でグループ（またはグループのサブセクション）を引き出します。私は通常、チームのランダムな人によって書かれたコードを選びます。できればゼロから書かれたコードを選択します。リファクタリングされたコードは、新しいコードのような問題を公開しません。

これらのレビューはエンバラスを意図したものではなく、パフォーマンスを反映するために使用されていないことを全員が知っていることを確認してください。彼らは単にあなたのチームのコーディング基準が守られていることを確認し、誰もがより良いエンジニアになるのを助け、したがってチームにとってより有用になり（そしてさらなるキャリア成長など）-これがレビューの真の意図であることを確認するためです。誰かが別の何かを疑う場合、これらは恐れられ、生産性が低下します。

私はやや非公式にコードを調べて、部屋の誰かに、彼らが持っているかもしれないさまざまな解決策や遭遇する論理的な欠陥を指摘させます。これは、そこに座っているリーダーがコーディングの方法を全員に伝えるというよりも、グループでの議論になることを意味します。

これらの2つの方法を使用すると、エンジニアの進捗率が向上し、バグ数が大幅に減少することがわかりました。

ペアプログラミングを実際に行ったことはないので（期待されているだけです）、2つのプラクティスを直接比較することはできません。ただし、正式なコードレビューの経験を伝えることはできます。

以前のプロジェクトでは、レガシーコードに関する正式なコードレビューを指揮していました。このプロジェクトは完全に混乱しており、経営陣は秩序を混乱に陥れることを期待してあらゆるイニシアチブを歓迎しました。当時、私は正式なコードレビューは良いアイデアだと思っていました。バグを見つけましたが、新しく作成したコードの品質は古いコードの品質よりもはるかに優れていることがわかりました。これを証明するために、統計、バグ数などを収集しました。

週に1回、平均3〜5人のセッションを行いました。各セッションは、1人あたり約3〜4時間（準備を含む）かかり、200〜300行のコード（LOC）*を確認しました。このペースで、6か月以上の期間で、約50Kから約5K LOCをレビューすることができました。

振り返ってみると、非常に費用がかかったと感じています。このペースでは、レガシーコードベース全体をレビューするのに5年かかりました。OTOHが1週間に複数のセッションを行うと、開発からリソースが奪われることになります。もちろん、それはレガシーコードの典型的なジレンマです。しかし、新しく作成されたすべてのコードを正式にレビューすることでさえ、多くの時間がかかり、開発が大幅に遅くなります。

私の結論は、コードの最も重要な部分に焦点を当てて、新しく書かれたコードで正式なコードレビューを行うのが最善であるということです。残りは、おそらく非公式な方法で、おそらくペアプログラミングを介してより適切に処理されます。しかし、これは私の現在の意見であり、変更される可能性があります。私はコードレビューの第一人者などとは言いません。

*これは、正式なコードレビューの通常のペースです。

一般的なコードレビュー率は、1時間あたり約150行のコードです。重要なソフトウェア（安全性が重要な組み込みソフトウェアなど）の1時間あたり数百行以上のコードの検査とレビューは、エラーを見つけるには速すぎる可能性があります。

ウィキペディアからの引用（私による強調）。

コードレビューが存在する根本的な理由は、孤立したプログラマーがコードに会って話し合い、コードが標準に準拠していることを確認する必要があるためです。

品質の問題については何も言及していないので、チームはすでにペアプログラミングを通じて十分なコードレビューを行っているようです。驚くばかり！

正しくプログラミングされたペアプログラミングは、正式なコードレビューを不要にします。しかし、数週間試してみて、どのように機能するかを確認しますが、改善点に気付かないと思います。

コードレビューは面倒で費用のかかるプロセスであり、軽視すべきものではないことに注意してください。それは本質的にあなたのプロジェクトに引き渡しを導入し、それは費用がかかりすべてを遅くします。後で問題を見つけようとするよりも、最初にコードが正しいことを確認する方がはるかに優れています。

多分。コードのレビューには時間がかかります。レビューにかかった時間がプロセスの別の時点で保存されている場合にのみ価値があります。コードレビューからどの程度の節約が期待できますか？コードレビューで防ぐことができる困難を経験していますか？

ペアプログラミングを行っている場合、コードレビューの必要性は大幅に減少しますが、ピアレビューのメリットは得られます。これが有益であるためには、ペアメンバーよりも年長で経験豊富な人がやらなければなりません。

利点は何ですか？まあ、それをしないことのリスクを考慮した方が良いでしょう。

• ペアは何か間違ったことをしている可能性があります。
• コーディング標準に従っていないか、コードを適切に文書化していない可能性があります。ピアレビューはこれらを見つけるのが本当に得意です
• ペア以外の誰も特定のコードを理解しません。それでは、ペアのメンバーが両方とも離れており、コードの文書化が不十分な場合はどうなりますか？他のものは、物事を理解しようとして時間を無駄にします。あなたがしたことを知っている第三者がいることは、リスクを軽減します。

コードレビューは時間の無駄だと人々が言っ​​ているのを楽しみにしています。はい、時間がかかります。コードに変更を加えることはないかもしれませんが、それが無駄になるわけではありません。それは時間の無駄だから、消防システムを定期的にチェックする必要はないと言っているようなものです。

私にとってコードレビューの主な利点は、人々がより良いコードを書くことができることです。

コードが読み取られ、レビューされることを知っていると、コードの読みやすさと「正確さ」をより意識するようになります。コードがリポジトリに直行し、他の誰もコードを修正しないことがわかっている場合、使用法が変更されたときにフィールド名をリファクタリングしないなど、スリップする傾向があります。バックファクターなどに