レビューで個人を採点することは、私が取り組んできたほとんどの成功したシステム、おそらくすべてに反するものです。しかし、私が20年以上にわたって達成しようとしてきた目標は、バグの減少とエンジニア1時間あたりの生産性の向上です。個人の採点が目標であれば、レビューを使用できると思います。労働者として、あるいはリーダーとして、それが必要とされる状況を見たことはありません。
客観的な研究（ファーガンなど）と多くの一般的な知恵は、ピア関係がバグの削減と生産性の向上を目的としたコードレビューを促進することを示唆しています。働くマネージャーは、マネージャーとしてではなく、ワーカーとして参加できます。議論のポイントが記載されています。レビューアを満足させるための変更は一般に良いことですが、必須ではありません。したがって、ピア関係。
C、C ++、Javaのlintを使用して、さらに分析や判断を行わなくても受け入れられる自動化ツールはすべて適切です。定期的なコンパイル。コンパイラーはコンパイラーのバグを見つけるのが得意です。自動チェックの逸脱を文書化することは、自動チェックの微妙な告発のように聞こえます。逸脱を許可するコードディレクティブ（Javaと同様）は、かなり危険です。デバッグに最適で、問題の核心をすばやく取得できます。不十分に文書化された50,000行の非コメント行のコードブロックで、それを見つけるのはあまり良くありません。
いくつかのルールは愚かですが、施行するのは簡単です。たとえば、到達不能な場合でも、すべてのswitchステートメントのデフォルト。それは単なるチェックボックスであり、何にも一致しない値で時間とお金をテストする必要はありません。ルールがあれば、愚かさがあるでしょう、それらは密接にリンクされています。ルールのメリットは、その愚かさの価値があるはずであり、その関係は定期的にチェックする必要があります。
一方、「それが実行される」ことは、レビューまたはレビューの防御の前には美徳ではありません。開発がウォーターフォールモデルに準拠している場合、複雑なエラーが発見され解決される前に、コーディングが85％完了したときにレビューを行いたいと思います。実際の生活はウォーターフォールモデルではないため、いつレビューするかはやや芸術的であり、社会的規範になります。あなたのコードを実際に読んで、問題を探す人は金色です。これを継続的にサポートしている経営陣は、価格以上の真珠です。レビューは、チェックインのように早く、頻繁に行う必要があります。
私はこれらのことが有益だと感じました：
1）スタイル戦争なし。開いた中括弧は、指定されたファイルの整合性チェックのみの対象となります。すべて同じです。それで結構です。同じインデントの深さ** sと**タブ幅。ほとんどの組織は、大きなスペースとして使用されるタブの共通標準が必要であることを発見しています。
2） `不規則
looking
しないテキスト
line up is hard to read
コンテンツ用。
ところで、K＆Rは 5つの（5）スペースをインデントしたので、権威への訴えは無価値です。ただ一貫してください。
3）レビューするファイルの行番号が変更されていない、公開されているコピーは、レビューの72時間以上前にポイントする必要があります。
4）オンザフライのデザインはありません。問題がある場合、または問題がある場合は、その場所を書き留めて移動し続けます。
5）開発環境のすべてのパスを通過するテストは、非常に良いアイデアです。大規模な外部データ、ハードウェアリソース、顧客のサイトの使用などを必要とするテストは、莫大な費用がかかるテストであり、完全ではありません。
6）作成、表示、編集などのツールが存在する場合、または開発の初期段階で作成される場合は、非ASCIIファイル形式を使用できます。これは私の個人的な偏見ですが、1ギガバイト未満のRAMで支配的なOSが独自の方法で抜け出せない世界では、なぜ10メガバイト未満のファイルが何であるべきかを理解できませんASCIIまたは他の商業的にサポートされている形式以外。グラフィックス、サウンド、ムービー、実行可能ファイル、およびそれらに付属するツールには標準があります。いくつかのオブジェクトのバイナリ表現を含むファイルには言い訳はありません。
リリースされたコードのメンテナンス、リファクタリング、または開発のために、ブランチチェックインのゲートウェイとして、ディスプレイに座って古いものと新しいものの差分を見ながら、他の人によるレビューを使用していた同僚のグループ。私はそれが好きでした、それは安くて、速くて、比較的簡単でした。事前にコードを読んでいない人のためのウォークスルーは、開発者のコードを改善することはほとんどありませんが、すべての人にとって教育的です。
地理的に分散している場合は、同じものを見ている他の人と話しながら画面上の差分を見るのは比較的簡単です。それは、変化を見ている二人をカバーしています。問題のコードを読んだことのある大規模なグループにとって、複数のサイトは1つの部屋にあるすべてのサイトよりもそれほど難しくありません。共有のコンピューター画面とスクークボックスでリンクされた複数の部屋は非常にうまく機能します。サイトが多いほど、より多くの会議管理が必要になります。ファシリテーターとしてのマネージャーは、ここでキープを獲得できます。あなたがいないサイトをポーリングし続けることを忘れないでください。
ある時点で、同じ組織に回帰テストとして使用される自動化された単体テストがありました。本当に良かった。もちろん、その後プラットフォームを変更し、自動化されたテストは取り残されました。アジャイルマニフェストが指摘しているように、プロセスやツールよりも関係の方が重要であると、レビューの方が優れています。しかし、レビューが済んだら、自動化された単体テスト/回帰テストは、優れたソフトウェアを作成する上で次に重要な助けになります。
女性が「ハリー・メット・サリーのとき」で言うように、要件に基づいてテストを行うことができれば、彼女が持っているものを手に入れることができます！
すべてのレビューには、コーディングを超えるレベルで要件と設計の問題を把握するための駐車場が必要です。何かが駐車場に属していると認識されたら、レビューで議論を停止する必要があります。
コードレビューは、ハードウェア設計の回路図レビューのようにすべきだと思うことがあります。完全に公開され、徹底的で、チュートリアル、プロセスの終わり、ゲートウェイが構築およびテストされます。しかし、物理オブジェクトの変更には費用がかかるため、スケマティックレビューは重量級です。ソフトウェアのアーキテクチャ、インターフェイス、およびドキュメントのレビューは、おそらく重いはずです。コードはより流動的です。コードレビューはより軽量でなければなりません。
多くの点で、テクノロジーは特定のツールに関するものと同じくらい文化と期待に関するものだと思います。心を楽しませ、心に挑戦する「スイスファミリーロビンソン」/ フリントストーン / マクガイバーの即興演奏を考えてみてください。私たちは自分のものを機能させたい。それへの単一の道はありません。1960年代のAIプログラムによって何らかの形で抽象化および自動化できる「インテリジェンス」があった以上です。