コードレビューは良い習慣ですか？

私が働いている会社が新しいマネージャーを雇ったとき、彼らは私たちにすべての会議で誰かのコードを概観するように提案しました。私たちは2週間ごとに会議を開催しているため、開発者の1人がそのコードをプロジェクターに表示するたびに、他の開発者がそれについて議論します。

これは素晴らしいことだと思いました。各開発者はコードを書く際により慎重になり、経験をよりよく共有することができます。しかし、どういうわけか私たちはこれを忘れて、申し出は申し出のままでした。

これにはどのような利点があり、欠点はありますか？

コードレビューは素晴らしい習慣です。

間違いから学び、特定の問題が他の人によってどのように解決されるかを確認するのにおそらく最良の方法です。また、コードベースの品質を維持する最良の方法の1つです。

多くの企業でコードレビューが行われますが、すべてが従う特定のプロセスがあると言うことは困難です。

より正式なコードレビューでは、シニア（または複数のシニア）が開発者と一緒にコードをレビューし、提案と指導を同時に行います。

コードレビューの追加の利点（この質問についてコメントされているとおり）には、次のものがあります。

• 教えて学ぶのに最適な方法
• これらは、コードベース（スタイルとイディオム）の一貫性を改善し、維持するための最良の方法の1つです。
• プロジェクトで使用されるスタイルとイディオム、およびそれらの使用方法をチームメンバー全員が確実に理解できるようにします。
• コードレビューは、バグや設計上の欠陥を早期に発見するため、開発をスピードアップします（したがって、初期の開発を遅くする可能性がありますが、後の開発サイクルで利益をもたらします）
• コードレビュープロセスの合理化に役立つツールサポートがあります。

コードレビューは、特に新しいチームメンバーが乗っている場合、学習に非常に便利なツールです。まあ、それはピアレビュープロセスとしても知られています:)

コードレビューにはさまざまなタイプがあります。

• 肩越し – 1人の開発者がコード作成者の肩越しに見て、コード作成者の肩を調べます。
• 電子メールのパスアラウンド –ソースコード管理システムは、チェックインが行われた後、レビュー担当者にコードを自動的に電子メールで送信します。コメントからの抜粋： Tortiseに組み込まれた履歴/差分ツールを使用してソース管理から新しいリビジョンを取得するたびに、同僚の変更を調べるために時間を割くように管理者を説得することに失敗した
• ペアプログラミング -2人の著者が同じワークステーションでコードを一緒に開発します。これは、エクストリームプログラミングでは一般的です。
• ツール支援のコードレビュー –作成者とレビュー担当者は、ピアコードレビュー用に設計された専用ツールを使用します。

一つだけありassociated disadvantage、正式なコードレビューが持って準備にかなりの投資が必要ですレビューイベントと実行時間のために。

その他の参考文献を以下にリストします（より詳細なダイビングの測定値について）

• MSDN-コードレビュー
• アプリケーションが出荷される前に脆弱性を見つけて修正する
• Wikiリンク

その特定のプラクティスは非効率的であり、恥ずかしいと思われます-間違いを人々のグループ全体に指摘したい人。そのため、レビュー対象を選択できず、コードがまだ実稼働していない場合、これは人々を不快にする可能性があります。

コードがいつレビューされるかによって、コードレビューのコメントがコードに反映されるかどうかに大きな違いが生じます。開発者が本番コードのみを選択および選択できる場合、レビューコメントが実装されることはほとんどありません。開発者が他の人々が興味を持っていることを学んだ気の利いたテクニックを披露できるミーティングを開催するのは良いことですが、それはコードレビューではありません。それはトレーニングです。

QAに移行する前に、すべてのコードのコードレビューを行います。すべての作品。通常、コードレビューアと開発者のみが関与します。コードレビューアが正式に合格するまで、QAには行きません。そのため、開発者は変更を加える必要があります。私たちは、QAが発見できなかった多くの問題を発見し、迅速に修正しました（コードレビューでも見られないものを見つけます）。さらに、カウボーイコーディングを削減し、パフォーマンスの悪い人をすばやく特定するので、問題を修正し、アプリケーションに損傷を与える前にそれらを訓練または取り除くことができます。コードレビュー時間は、作業を計画する際の時間の見積もりの​​一部であるため、期限にまったく影響しません。実際、問題が早期に発見されるほど修正が容易になるため、長期的には時間を節約できます。

私は個人的に、コードレビューを通じて経験の浅い開発者に多くの優れたテクニックを教えてきました。また、他の人のコードと自分のコードに対するコメントをレビューすることで、自分自身より良いテクニックを学びました。さらにコードをレビューすることで、他の誰かがコードを理解していることを確認できます。これにより、コードのメンテナンス性が向上します。コードは機能する場合もありますが、レビューの質問により、コードが理解しにくいため、メンテナンスの問題があることがわかります。コード作成者でさえ頭をかきむしり、コードがなぜそんなことをするのか疑問に思っている1年後よりも、すべてがまだ新鮮である一方で、そのような場合にリファクタリングする方がよいでしょう。

このタイプのコードレビューの問題は、2週間に1人の開発者であり、進行は遅くなります。誰もが注目を浴びるまでに数ヶ月かかるかもしれません。

コードのレビューは優れている場合がありますが、その背後にある理由と、それらを実行する手順の背後にある必要があります。

いくつかの問題を決定する必要があります。

• 誰が開発者を選ぶのか、そして彼らはどれだけの注意を払うのか。予告なしのレビューはtrapです。
• レビュー対象のコードの一部を選択するのは、管理者、プロジェクトの上級開発者、またはレビュー対象の開発者です。
• コードがプロジェクターにある人にもっと良い方法を教えるための目的、またはコードがプロジェクターにある人が部屋の他の人にコードを改善する方法を教えるための目的です。
• この方法でレビューされるコードの割合はどれですか？これはQAプロセスの一部になりますか？

この計画を提案した人々がこれらの質問への回答をまだ持っていない場合、すべての偉大な企業がどのようにコードレビューを行っているかについての記事を読む可能性があります。

コードレビューは、コードレビューのアイデアが開発チームから来た場合にのみ有効です。開発者は、お互いのコードをレビューするためにプロジェクターとプレゼンテーションを必要としません。彼らがしたい場合-彼らは会議に行くことを好むでしょう。

コードレビューのアイデアが経営陣から生まれたとき、それは低いソフトウェア品質の調査のように聞こえ、開発チームの士気を低下させる可能性があります。管理チームがコードレビュープロセスに関与すべきだとは思わない。管理チームと並んでコードレビュー-非常に悪い、殺人と破壊的な練習。

特に、開発者が知識を共有するためにコードレビューを行う場合、コードレビューは優れた実践であり、提案と批判は建設的であり、個々の開発者を対象の実践に使用しないことを前提とする基本ルールが事前に設定されています。

開発者ではない管理者は、コードレビューを行うことを決定した場合、開発者による疑いで迎えられます。ほとんどのマネージャータイプは、開発者がコードを見るときに本質的に入り込む詳細を知りたくないでしょう。また、ほとんどのマネージャーは、開発者があるアプローチを別のアプローチよりも批判する理由を理解しません。

開発者が管理のために行っている優れた作業を紹介したい場合、「コードレビュー」は異なる意味を持ち、開発者間でコード品質を指導/改善するために行われるコードレビューほど詳細にすべきではありません。この種のプレゼンテーションは、管理者が理解するもの（価値、ROIなど）に焦点を当てて、プレゼンテーションのレベルを高め、コード固有性を低くすることができる場合の開発者の行動を示すのに役立ちます。ジョーがXを構築することで会社に大きな価値を追加したことをマネージャーに理解させるかもしれません。これはYの時間の節約、注文ごとのZドルなどを示すことができます。あなたのチームのメンバー。ただし、専門用語や詳細レベルが多すぎて視聴者を圧倒しないように注意する必要があります。

私が強調したいのは、コードレビューが教える上で非常に建設的であることには完全に同意しますが、とにかく、チームの設計パターンが正しくフォローされていることを確認することです。

私たちは少しプロトタイプの作品を書き、コードのリファクタリングを行い、最終的には製品に満足していると感じていますが、読みやすさは損なわれています。

独立した目は、あなたが特定の思考様式にとらわれており、これがすべての経験レベルであるため、常に有益です。設計とコードに何時間も投資したため、努力が無駄になる恐れがある場合、コードのレビューに対処することは困難です。それでも、最終的には、よりクリーンで、より管理しやすいアプリケーションになり、経験があなたに染み込んでくれることを願っています。

私たちのチームでは、@ ElYusubovが述べたように、コードレビュー専用のツール-Crucibleを使用します。人々はコードをレビュー、コメント、サインオフします。毎週私たちは座って、面白くて複雑なコードを直接確認します。

ソフトウェアエンジニアリングのインターンとして、コードレビューが非常に役立つことがわかりました。

私のチームでは、コミットごとにコードレビューが必要です（大きな変更は正式なものになり、小さな変更は「クイックルック」になります）。特に「見られている」ことを知っているので、すぐに端末よりもホワイトボードを引き抜く可能性が高いため、エンジニアリング/デザインのチョップがこれによって後押しされているように感じます。:)

実際には、開発時間がわずかに遅いというわずかな欠点があるだけで、はるかに優れたコードが生成されると思います（私の意見では、ひどく設計されたコードを修正/拡張する必要がない場合、これは価値があります）。また、チームにジュニア/インターンがいる場合、貴重なフィードバックの機会に感謝していると思います。私は知っています！

私の経験から言えば、コードレビューはうまく行けば本当に素晴らしいことです。プロ/成熟したチームメンバーとマネージャーがいる場合。プログラマーとしての私たちは「ソリューションソルバー」です。私たちの仕事は、「テキスト」の行を作成することではありません。だからこそ、アイデア、間違い、問題、経験を共有しなければなりません。これを実現するには、コードレビューを行うことをお勧めします。

残念ながら素晴らしいように聞こえますが、ほとんどの企業で実装するのは本当に難しいです。あなたのチームには多くの「自律性」が必要です。新しい機能を作成しないことが有益であるとあなたのマネージャーまたは財務部門を説得するのは難しいようです。

私の会社では、コードのレビューを試みています。しかし、「ウサギを追いかける」（機能を作成する）には時間がかかりすぎます。

スタイルと基本的な構文タイプのチェックの多くは、最近のツール（FXCopなど）を使用して検出されます。

ただし、特にチームの新しいメンバー、複雑で影響の大きいもの（失敗した場合やビジネスに影響を与えた場合に重要な人に気付くようなもの）、特に短期の請負業者をアウトソーシングまたは使用する場合（特に再び）、コードレビューは良好です翻訳エラー/言語の問題により、ソフトウェアがすべてのテストに合格することはできますが、本来想定されていることを実行できないため、ネイティブスピーカーではない場合。

私は、チームが選択できるようにプロジェクターにコードを置くのが好きではありません。他のチームメンバー（チームリードなど）が開発者とリストを行うコードレビュー会議を開催する方がずっと良いです。これは、より少ない人に影響を与えます-スタイルの引数に費やされる多くの時間を止めます-そして、開発者にとって恥ずかしさは少なくなります。開発者が実際の問題を吸収し、「私はこれをやっただろう...」というコメントに盲目にされることは、より建設的で簡単です。

また、強制されていないコードレビュー-共有にコードを配置したり、誰かが昼食時間をあきらめてそれをやり遂げることを望んでメールで送信したりすることは、時間の無駄だと思います。

これには、リストの山、マーカー、コーヒーエリアでのコーヒーカップと一緒に座っておくのが最適です。

この種のグループショーアンドテルは、新しいテクノロジーや複数のjrを取得するのに適しています。開発は進んでいますが、新しいコードの一貫したレビューほど優れているとは思いません。1対1で行う方が効率的です。

コードレビューは「全体」を見るのに役立ちます。別々の開発者は、自分の要件/問題だけを見る傾向があります。CRは全体の観点からアイデアとソリューションを発見します。CRは、主に不要な作業の無駄をなくすのに役立ちます。製品全体が安く、品質が良いです。