コードレビューは良い習慣ですか？
私が働いている会社が新しいマネージャーを雇ったとき、彼らはすべての会議で誰かのコードの概要を説明してくれました。私たちは2週間ごとに会議を開いているので、開発者の1人が自分のコードをプロジェクターに表示するたびに、他の人がそれについて話し合う予定でした。
これは素晴らしいことだと思いました。コードを書くときは、各開発者がより注意深く、経験をよりよく共有できます。しかし、どういうわけか私達はこれを忘れ、申し出は申し出のままでした。
これにはどのような利点がありますか、また欠点はありますか？
コードレビューは素晴らしい習慣です。
これはおそらく、間違いから学び、特定の問題が他の人によってどのように解決されるかを確認するための最良の方法です。また、コードベースの品質を維持するための最良の方法の1つでもあります。
コードレビューは多くの企業で行われますが、それらすべてが従う特定のプロセスがあるとは言いがたいです。
より正式なコードレビューでは、シニア（または複数のシニア）が開発者と一緒にコードをレビューし、提案と指導を同時に行います。
（この質問についてコメントされた）コードレビューの追加の利点には、次のものがあります。
- 教える、学ぶための素晴らしい方法
- これらは、コードベース（スタイルとイディオム）の一貫性を改善および維持するための最良の方法の1つです。
- これらは、すべてのチームメンバーがプロジェクトで使用されるスタイルとイディオム、およびそれらの使用方法を理解するのに役立ちます
- コードレビューは、バグや設計の欠陥を早期に発見するため、開発をスピードアップします（したがって、初期の開発が遅くなる可能性がありますが、後の開発サイクルで成果を上げます）。
- コードレビュープロセスを合理化するのに役立つツールのサポートがあります
コードレビューは、特に新しいチームメンバーが参加している場合に、学習用のツールが非常に役立ちます。まあ、それはピアレビュープロセスとしても知られています:)
コードレビューにはさまざまな種類があります。
- Over-the-shoulder– 1人の開発者がコード作成者の肩越しに、コード作成者がコードをウォークスルーします。
- メールの受け渡し–ソースコード管理システムは、チェックイン後にコードをレビュー担当者に自動的にメールで送信します。 コメントからの抜粋：ソース管理から新しいリビジョンをプルダウンするたびに、同僚の変更を確認するために取ったあらゆる種類の正式なコードレビューに時間を割り当てるよう経営陣を説得することに失敗しましたトルテスに組み込まれた履歴/差分ツールを使用する
- ペアプログラミング– 2人の作成者が同じワークステーションで一緒にコードを開発します。これは、エクストリームプログラミングでは一般的です。
- ツールを使用したコードレビュー–著者とレビューアーは、ピアコードレビュー用に設計された専用ツールを使用します。
正式なコードレビューでレビューイベントと実行時間の準備にかなりの投資が必要なassociated disadvantageは1つだけです。
より多くの参照が以下にリストされています（より詳細な測定値の場合）
その特定の慣行は非効率的で恥ずかしいようです-間違いを人々のグループ全体に指摘したい人は。したがって、レビュー対象を選択できず、コードがまだ本番環境にない場合、これは人々を不快にする可能性があります。
コードがいつレビューされるかによって、コードレビューコメントがコードに組み込まれるかどうかに大きな違いが生じます。開発者がプロダクションコードのみを選択できる場合、レビューコメントは実装されない可能性があります。開発者が他の人が興味を持っていることを知った気の利いたテクニックを披露できる会議を開くのはいいことですが、それはコードレビューではありません。それはトレーニングです。
QAに移行する前に、すべてのコードのコードレビューを行います。すべての作品。通常、コードのレビュー担当者と開発者のみが関与します。コードレビューアーが正式にそれを渡すまで、QAには行きません。したがって、開発者は変更を行う必要があります。 QAでは発見されなかった多くの問題を発見し、すぐに修正しました（コードレビューには見られないものも発見されます）。さらに、カウボーイコーディングを削減し、パフォーマンスの低い人々をすばやく特定できるため、アプリケーションに損傷を与える前に問題を修正し、トレーニングまたは排除できます。コードレビュー時間は、作業を計画する際の時間の見積もりの一部であるため、締め切りにまったく影響しません。そして実際には、問題を早期に発見するほど修正が容易になるため、長期的には時間を節約できます。ちなみに、コードレビューアはマネージャではなく仲間であり、コードのレビューにはあらゆるレベルの人々が関与しています。
私は個人的に、経験の浅い開発者にコードレビューを通じて多くの優れたテクニックを教えてきました。他の人のコードと私のコードへのコメントをレビューすることで、いくつかの優れたテクニックを自分で学びました。さらにコードをレビューすることで、他の誰かがコードを理解できるようになり、コードの保守性が向上します。時々、コードは機能しますが、レビューの質問により、コードが理解しづらいため、メンテナンスの問題があることが明白になります。コード作成者でさえ頭を悩ませて、なぜコードがそのようなことをするのか疑問に思う1年後よりも、すべてがまだ心の中で新鮮なままである場合にリファクタリングする方が良いでしょう。
このタイプのコードレビューの問題は、2週間ごとに1人の開発者がいるため、進行が遅くなります。誰もが注目を浴びるまでに数か月かかる可能性があります。
コードレビューは良いことかもしれませんが、それらの背後に、そしてそれらを行うための手順の背後に理由があるはずです。
いくつかの問題を決定する必要があります：
- 誰が開発者を選ぶのか、そしてどの程度の注意を払うのか。予告なしのレビューは罠です。
- 誰がレビュー対象のコードの部分を選ぶか：管理、プロジェクトの上級開発者、またはレビュー対象の開発者。
- プロジェクターにコードが付いている人に何か良い方法を教える目的、またはコードがプロジェクターにある人がコードを改善する方法を部屋の周りにいるすべての人に教える目的です。
- この方法でレビューされるコードの割合は何パーセントですか？これはQAプロセスの一部になるのでしょうか？
この計画を提案した人がまだこれらの質問に答えていない場合、すべての優れた企業がコードレビューを行う方法についての記事を読む可能性があるので、その背後にある目的を理解せずにそれらも行う必要があります。
コードレビューは、コードレビューのアイデアが開発チームから出された場合にのみ、優れた方法です。開発者は、お互いのコードをレビューするためにプロジェクターやプレゼンテーションを必要としません。彼らがしたい場合-彼らは会議に行くことを好むでしょう。
コードレビューのアイデアが管理から生まれた場合、ソフトウェア品質の低下の調査のように聞こえ、開発チームの士気を低下させる可能性があります。管理チームがコードレビュープロセスに関与すべきではないと思います。管理チームと並んでコードレビュー-非常に悪い、殺害、破壊的な実践。
コードレビューは、特に開発者が知識を共有するために行われる場合、優れたプラクティスであり、提案や批判は建設的であり、個々の開発者をターゲットプラクティスに使用しないことを意図した基本ルールが事前に設定されています。
開発者ではないマネージャーは、コードレビューを行うことにした場合、開発者の疑いで迎えられます。ほとんどのマネージャタイプは、開発者がコードを調べるときに本質的に取得する詳細を知りたくないでしょう。ほとんどのマネージャーは、開発者がなぜ1つのアプローチを他のアプローチよりも批判するのか理解しません。
開発者が管理に対して行っている良い仕事を紹介したい場合、「コードレビュー」は別の意味を持ち、開発者の間でコード品質を指示/改善するために行われるコードレビューほど詳細ではありません。この種のプレゼンテーションは、マネージャーが理解するもの（値、ROIなど）に焦点を合わせて、プレゼンテーションがより高レベルでコード固有ではない場合に開発者が行うことを示すのに役立ちます。ジョーがXを構築することで会社に重要な価値を追加したことをマネージャーに理解させるかもしれません。これにより、Yの時間の節約、または注文ごとのZドルの節約などを示すことができます。あなたのチームのメンバー。ただし、専門用語や詳細レベルが多すぎて視聴者を圧倒しないように注意する必要があります。
私の経験から、コードレビューは、うまく実行すれば本当に素晴らしいことです。プロ/成熟したチームメンバーとマネージャーがいる場合。私たちプログラマーは「ソリューションソルバー」です。私たちの仕事は「テキスト」の行を作成することではありません。そのため、アイデア、間違い、問題、経験を共有する必要があります。コードレビューは、これを実現するための本当に良い習慣です。
残念ながらそれは素晴らしいように聞こえますが、ほとんどの企業で実装することは本当に難しいです。チームには多くの「自律性」が必要です。新しい機能を作成しないことが有益であるとマネージャーや財務部門に納得させることは難しいようです。
私の会社では、コードレビューを行っています。しかし、「うさぎを追いかける」（機能を作る）ことに時間をかけすぎています。
私が強調したいことを教えるためにコードレビューは非常に建設的であることに完全に同意しますが、いずれにしても、チームの設計パターンが正しく行われていることを確認することです。
私たちは小さなプロトタイプ作品を書き、コードの一部をリファクタリングし、最終的に製品に慣れている間、読みやすさが損なわれています-人々はそれを見て、何が起こっているのかはっきりと見ることができません。
独立した目は常に有益だと思います。特定の思考モードにとらわれてしまうので、これはすべてのレベルの経験です。あなたは設計とコードに何時間も投資したので、あなたの努力が放棄される恐れがあるとき、コードレビューは対処するのが難しいです。それでも、最終的には、よりクリーンで無駄のない、より管理しやすいアプリケーションが実現し、エクスペリエンスが定着します。
私たちのチームでは、@ ElYusubovが言及したように、コードレビュー専用のツール-Crucibleを使用しています。人々はコードをレビュー、コメント、サインオフします。毎週座って、面白くて複雑なコード片を対面で確認します。
スタイルや基本的な構文タイプのチェックの多くは、最近のツール（FXCopなど）を使用して行われています。
ただし、コードレビューは、特にチームの新しいメンバー、複雑または影響が大きいもの（たとえば、失敗したりビジネスに影響を与えたりすると重要な人に気付くようなもの）、特にアウトソーシングや短期の請負業者を使用する場合（特に再び）翻訳エラー/言語の問題が原因でソフトウェアがすべてのテストに合格できるが、実際には想定されていることを実行できないため、ネイティブスピーカー以外の場合）。
私はチームがプロジェクターを透過してコードを確認するのが好きではありません。別のチームメンバー（チームリーダーなど）が開発者とリストを確認するコードレビューミーティングを行うのがはるかに良いです。これは、より少ない人々に影響を与えます-スタイルの議論で多くの無駄な時間を止めます-そして、開発者にとって恥ずかしいことではありません。開発者が実際の問題を吸収し、「私はこれを行っていただろう...」というコメントに惑わされない方が、建設的で簡単です。
また、強制されていないコードレビュー（共有にコードを配置したり、誰かがそれを通過するための昼食時間をあきらめることを期待してメールで送信したりするなど）は、時間の無駄だと思います。
リストの山、マーカー、コーヒーエリアのコーヒーカップを並べて座るのは、このために最適です。
ソフトウェアエンジニアリングインターンとして、コードレビューは非常に役に立ちました。
私のチームでは、コミットごとにコードレビューが必要です（大きな変更は最終的には正式なものになり、小さな変更は最終的には「クイックルック」になります）。特に私が「監視」されていることを知っているので、ターミナルよりもすぐにホワイトボードを引き出す可能性が高いので、私のエンジニアリング/デザインチョップはこれによって後押しされているように感じます。 :)
実際、私はそれがはるかに優れたコードを生成すると思いますが、わずかな欠点は開発時間が少し遅いことです（私の意見では、ひどく設計されたコードを修正または拡張する必要がない場合、長期的には価値があります）。また、チームにジュニア/インターンがいる場合は、貴重なフィードバックが得られる可能性が高く評価されると思います。私は知っています！
この種のグループショーアンドテルは、新しいテクノロジーやいくつかのjrを取得するのに適しています。開発速度は最高ですが、新しいコードの一貫したレビューほど良いとは思いません。 1つずつ行う必要がある方が効率的です。