コードレビュー、利点は何ですか？
私のチームでは、正式なコードレビューは行っていません。ペアプログラミングとペアの回転で十分であると考える傾向があります。
正式なコードレビューを検討する必要がありますか？利点は何でしょうか？
コードのレビューは少し異なります（たぶん）。
私たちはすべてのプログラマーを集めて（毎週金曜日）、1週間で何をしたかを調べます。次に、どのプロジェクトをレビューするかを選択しました。これにより、すべての完了/進行中のプロジェクトに少なくとも1人または数人が参加するようになります。次に、1時間ほどで、加えられた変更を確認し、間違いを検索し、他のプロジェクトがどのように機能するかなどを確認します。その後、間違いについて説明し、どのようにすべきかを説明します（バグを修正するのではなく、指摘するだけです）。 FIXMEを使用してコードをスパムする）。全体として、通常、私たち（プログラマー10人）は約2時間かかります。
長所：
- すべてのメンバーは会社で何が起こるか知っています
- バグがより早く発見されます
- それは私たちに読み取り可能なコード（説明や紹介なしで読むことができるコード）を書くことを強制します！
- 最適化の方法/トリック/生産的なプログラムはより速く広がります
- スペシャリストとしてのプログラマーはより速く「進化」する
- 楽しいです
前述のようにペアプログラミングに反対しているのは（私の個人的な意見にすぎないことを確認してください）、チームの連携が長ければ長いほど、速度が上がるということです。
私はそれが思考のためのいくつかの食べ物をもたらすことを願っています。幸運を。
この無料の本を読みたいと思うかもしれません：
http://smartbear.com/best-kept-secrets-of-peer-code-review/
確かに、彼らはプッシュする製品を持っていますが、そこにはまだ多くの有用な情報があります。
また、ペアプログラミングが同じ利点のいくつかを提供する方法についても説明しているため、ペアプログラミングをしている場合は、コードレビューをまったく必要としない場合があります。
私はあなたの環境でレビューする経験があまりありません。ここでは多くのペアプログラミングを行っていません。コードレビューを行って、チーム内のソフトウェアの知識を広め、間違いを見つけるための別の目を持ち、ソフトウェアがコーディングガイドラインに準拠しているかどうかを確認する正式なポイントを持っています。 。
最初の2つのポイントはペアプログラミングでかなりカバーされており、3番目はペアに非常に依存しており、正式なコードレビューからより良くなる可能性があります。
私は実際にペアプログラミングをしたことがないので（期待していただけです）、2つの方法を直接比較することはできません。しかし、私は正式なコードレビューでの経験を伝えることができます。
以前のプロジェクトでは、以前のコードで正式なコードレビューを率いていました。プロジェクトは完全に混乱しており、混乱に秩序をもたらすことを期待して、経営陣はあらゆるイニシアチブを歓迎しました。当時、私は正式なコードレビューが良いアイデアだと思いました。バグを発見し、新しく作成したコードの品質が古いコードの品質よりも大幅に優れていることを確認しました。これを証明するために、統計、バグ数などを収集しました。
平均して週に1回のセッションを行い、3〜5人が参加しました。各セッションは1人あたり約3〜4時間（準備を含む）かかり、200〜300行のコード（LOC）*を確認しました。このペースで、6か月以上の期間で、約5万件のうち5万件のLOCを確認することができました。
振り返ってみると、それは非常に高価だったと思います。このペースでは、レガシーコードベース全体を確認するのに5年かかりました。 OTOHが週に2回以上のセッションを持つことは、開発からリソースを奪っていただろう。もちろん、それはレガシーコードの典型的なジレンマです。しかし、新しく作成されたすべてのコードを正式にレビューする場合でも、かなりの時間がかかり、開発が大幅に遅くなります。
私の結論は、正式なコードレビューは、コードの最も重要な部分に焦点を当てて、新しく作成されたコードで行うのが最善であるということです。残りは、おそらく非公式な方法で、おそらくペアプログラミングを介してより適切に処理されます。これは私の現在の意見ですが、変わる可能性があります。コードレビューの第一人者であるとは主張していません。
*これは正式なコードレビューの通常のペースです。
一般的なコードレビュー率は、1時間あたり約150行のコードです。重要なソフトウェア（たとえば、1時間あたり数百行を超えるコードの検査とレビュー安全上重要な組み込みソフトウェア）は、エラーを見つけるには速すぎる場合があります。
Wikipedia から引用（私が強調）.
コードレビューが存在する根本的な理由は、孤立したプログラマーがコードに会って話し合い、コードが標準に準拠していることを確認する必要があるためです。
品質の問題については何も触れていないので、チームはすでにペアプログラミングを通じて十分なコードレビューを行っているようです。驚くばかり！
ペアプログラミングを正しく行うと、formalコードレビューが不要になります。しかし、数週間試してみて、どのように機能するかを確認してください。しかし、改善に気付かないでしょう。
コードレビューは骨の折れる費用のかかるプロセスであり、簡単に行うべきものではないことに注意してください。それは本質的にあなたのプロジェクトに高額なハンドオーバーを導入します すべてを遅くします 。後で問題を見つけようとするよりも、最初からコードが正しいことを確認する方がはるかに優れています。
正式なコードレビューを行うべきですか？
絶対に
簡単な補足として、私は非常にペアプログラミングの経験がほとんどありませんが、レビューがこれらの方法と競合することはないと思います。
コードレビューの2つの形式を紹介します。
ピアコードのレビュー
ペアプログラミングが機能する場合でも、neverは、コードに別の目を向けるのが難しくなります。これの利点は次のとおりです。
- それはコードに新鮮な目を向け、あなた（そして/またはあなたのパートナー）がコードベースの領域に精通していないかもしれない誰かに精通しているかもしれません。これにより、ノックオンの問題が発生する可能性があります。
- 提出前に、あなた（ペア）がソリューションを再検証します。レビュアーはあなたが書いたものについて何も知らないので、それを完全に説明する必要があります。これにより、考えていなかったEdgeのケースや無効なロジックが明らかになる可能性があります。
ピアコードのレビュー（私の世界では）はeveryの提出前に行われます。ペアプログラミングの世界でこれがどのように引き継がれるか、私にはわかりません。
グループコードのレビュー
これらは、ピアコードレビューほど頻繁には発生しません。私は通常、グループ（または私のグループのサブセクション）を会議室に引き込み、コードを非公式にレビューします。私は通常、チームのランダムな人物が作成したコードを選択します。できれば、ゼロから作成したコードを選択します。リファクタリングされたコードは、新しいコードのような問題を明らかにしません。
これらのレビューがnotがエンバラスを意図しており、パフォーマンスを反映するために使用されていないことを誰もが知っていることを確認してください。彼らは単にあなたのチームのコーディング基準が守られていることを確認し、everyoneより良いエンジニアになり、チームにとってより有用になる（そしてさらにキャリアの成長などになる）ために-そしてこれを確実にすることですレビューの真の意図です。誰かが何か違うと疑う場合、これらは恐れられ、生産性が低下します。
私はコードをいくぶん非公式に検討し、部屋の誰もが彼らが持っているかもしれないさまざまな解決策や彼らが遭遇する論理的な欠陥を指摘するようにしました。これは、そこに座ってリーダーがコーディング方法を全員に伝えるよりも、グループディスカッションのようなものです。
これらの2つの方法を採用すると、エンジニアの進捗率が向上し、バグ数も大幅に減少することがわかりました:)
ペアプログラミングを行う場合、コードレビューの必要性は大幅に減少しますが、ピアレビューのメリットは確かに得られます。これが有益であるためには、ペアのメンバーよりもシニアで経験のある人がそれを行う必要があります。
メリットは何ですか？まあ、それをしないことのリスクを考慮した方がいいでしょう。
- ペアは何か間違っているか、多分最適ではない方法でそれをしている可能性があります
- たぶん、あなたはコーディング標準に従っていないか、コードを適切に文書化していません。ピアレビューはこれらを見つけるのに本当に良いです
- ペア以外の誰も特定のコードを理解しません。では、ペアのメンバーが両方とも去って、コードが十分に文書化されていない場合はどうなりますか？他の人は物事を理解しようとする時間を無駄にします。あなたがしたことを知っている第三者がいることはリスクを減らします。
コードレビューは時間の無駄だと人々が言ったことを私は面白がっています。はい、時間がかかります。たぶんそれはコードに変化をもたらさないかもしれませんが、それはそれが無駄になっていることを意味しません。それは時間の無駄なので、定期的に消火システムをチェックする必要がないと言っているようなものです。
私にとってコードレビューの主な利点は、人々がより良いコードを書けるようになることです。
コードが読み取られてレビューされることを知っていると、コードが読みやすくなり、コードの「正確さ」が高まります。コードがリポジトリに直接入っており、他の誰もそれを修正しない限りそれを読み取らないことがわかっている場合は、使用法が変更されたときにフィールド名をリファクタリングしないようにして、未使用のメソッドが残っている可能性がある場合にぶらぶらする傾向があります等に因数分解される.
多分。コードレビューには時間がかかります。レビューにかかる時間がプロセスの別の時点で節約される場合にのみ、それらは価値があります。コードレビューによりどの程度の節約が期待できますか？コードレビューによって防止できる問題が発生していますか？