また、すべての点で著者に同意していないことに注意する必要があります（最後に彼は既に掘り下げを開始しています）、そしてもちろん、コードレビューは特効薬ではありませんが、それでも非常に有用なプラクティスです）
先週、CIO.comでコードをレビューする5つの理由についてこの記事を取り上げましたが、実際にはそこに記載されている5つ以上の理由があることに気付きました。 そのため、1日の終わりにはすでに20個を超えていました。これは、これらのツイートのコレクションであり、ここで説明する詳細の一部が含まれています。
理由＃1。 開発者に拍車をかけるのに十分な高速応答。
コードレビューは、コーディング後、統合およびシステムテストの前に行われるため、開発者はコード品質部門（QA）からの応答を待つ必要がありません。 具体的でタイムリーな応答を提供することにより、開発者はコーディングスキルを調整して、よくある間違いを回避できます。
理由番号2。 単一のテストを使用するよりも多くのエラーを見つけます。
これは明らかです。テストはエラーを見つけます。 コードレビューで他のエラーを見つけます。 一緒に使用すると、製品を顧客に送信する前に見つけたよりも多くのエラーが見つかります。
理由番号3。 何も意味しない場合でも、100万匹の猿に有効な構文がある場合があります。 コンパイラはこれを追跡できません。
コンパイラが追跡できないように、有効なコードで構成される構文エラーを作成する場合があります。 Cの古典的な同様のエラーは、=（割り当て）と==（ブール等価演算子）です。 この場合、ほとんどのコンパイラーは警告を出すことができますが、他の例もあります。 コードを確認すると、このようなエラーがすぐに明らかになりますが、テストで見つけるのは非常に困難です。
理由番号4。
コードレビューからエラーレポートを取得すると、正確な行番号と問題の説明が既にあります。 システムテストまたは（恐ろしい！）ユーザーからレポートを受け取ると、せいぜい、エラーを再現するための一連の手順があります。 それから、コード内でエラー自体を見つけることができるかどうかは、特にコードが数週間または数か月前に書かれている場合、通常かなり時間がかかります。 （理由＃1を参照）
理由番号5。 初心者を訓練します。
コードレビューは効果的な学習ツールです。 まず、コードレビューに参加している初心者プログラマーは、他のプログラマーのコードにアクセスできるため、コーディング標準とドキュメントスタイルを「体験」できます。 さらに、経験の浅いプログラマは、システムにベースコードを感染させる機会を得る前に、コードの評価を受け取ります。 （私たちは皆、10年前に書いたコードが恐ろしいことを知っているので、それは彼が年配の開発者からレビューを得るのに十分幸運でなかった場合のみです。数年未満のプログラミングをしているなら、恐ろしいかもしれませんが、もう数年は感謝することができません。理由6を参照してください。）
理由＃6。 開発当初から、コードの品質を強制するために開発者のエゴが使用されてきました。
ここでの理論は次のとおりです。コードが同僚のグループによって公開され、慎重に検査されることを知っているため、開発者はコード内のあらゆる種類のエラーを見つける際に恥を避けるためにより慎重に作業します。
ゲスト@kyletolleからのコメント：理由＃7。 コードの明確化は、その理解を保証します。 「Nuu、私はいつもやった…」のようなマークは削除されました。
レビュー中に同じ質問に数回答えなければならない場合、コーディング中に質問することもできます。 （理由＃6を参照）
理由番号8。 テストを高速化します。 地獄、開発全体を加速します！
これにはいくつかの主な理由があります。 まず、コードレビューがその場所で直接欠陥を検出して修正するため（理由4を参照）、それに応じて、修正に費やす時間が短縮されます。 第二に、テスターはエラーが少ないため、質問のコンパイルにかかる時間を短縮でき、開発部門はそれについて口論します。 第三に、製品のリリース候補が少なくなるため、テスト担当者は回帰テストを何度も再起動する必要がありません...そして最後に、テスト担当者はバグ修正を待つことなくアイドル状態になりません。
理由番号9。 怒っているユーザーの数が少なければ少ないほど、あなたの技術サービスは幸せになります。 サポート。 。
証拠：製品のバグが少ない（理由＃2を参照）。 なぜなら バグはそれほど頻繁にユーザーを悩ませませんが、後者は悪である可能性が低くなります。 したがって、ユーザーが最終的に電話をかけると、彼らはあなたを称賛します。 （さて、歌についての部分は完全に真実ではないかもしれませんが、あなたは一般的な意味をつかんだと思います。）一方、証拠：バグの修正に費やす時間が少ない場合、要求される新しい機能の開発により多くの時間を費やすことができますユーザー。
理由番号10。 （反理由）売り上げが増えるため、より多くのコミッションを支払う必要があります...ちょっと、それは素晴らしいことです！
ユーザーが製品の安定性を称賛するとき、新しいユーザーの両方に販売し、既存のユーザーに売り上げを増やすのが簡単です。 もちろん、販売手数料は上がりますが、これについて大声で不満を言う人はいません。
理由11。 「クラシック」レビュープロセスの迷惑な要素を減らすツールがあります。
（translに注意してください。ツールのリストは、この非常に短い記事で後ほど説明しました。すべての情報を1か所で収集するために、このルールに直接挿入することにしました）。
以下に、特定の順序なしのレビューツールのリストを示します。 私はそれらすべてを試したわけではないので、それらは比較なしで与えられます。 他のツールを知っている場合は、コメントを残してください。リストに追加します。
Codestriker-オープンソースのWebソリューションはPerlで書かれているようです。
コードコラボレーター -有料製品。
レビューボード -オープンソース（オープンソース）Webソリューションは、Python / Djangoで記述されているようです。
Rietveld -Googleのオープン（オープンソース）ソリューション。 調査ツールに関するGuido van Rossumの第2の試み。 それが書かれているものの3倍から推測します...
るつぼ -アトラシアンの有料製品。
結論：手動で実行しようとしないでください。パッチの送信と欠陥の追跡に多くの時間を費やしますが、ツールはこれを自動的に実行できます。
理由＃12。 リスクはゼロです。 それほど効果的ではないレビューでさえ、テストに勝ります。
少し時間を費やせば、この理由を正当化するために公開された研究を掘り下げることができます。 しかし、私の個人的な経験では、コードレビューは単体テストよりも約4倍効率的です。 したがって、あまり熱心にレビューを行わなくても、テストよりも効果的です。 （理由＃2と＃4を参照してください。また、理由＃5を念頭に置いてください。これはすぐに測定可能な効果を与えません。）また、コードレビューは時間の無駄であるというデータも必要です。 いくつかの空飛ぶ鹿も可能です。 （Steve McConnellの著書「Perfect Code」で翻訳されたメモでは、テスト前にコードレビューの有効性を確認する非常に多くの研究結果が得られ、これらの両方の手法を使用すると、どの手法を使用するよりもはるかに良い結果が得られることが示唆されていますそれらの1つ。）
理由番号13。 （反理由）多くの間違いを見つけることができないので、テスターは退屈します...ああ、はい！ 彼らはストレス/ストレステストに集中することができます。 私はそのような問題があればいいのに...
理由14。 測量は、調査を実施するための良い習慣です。 あなたは良くなっています。
チームでのレビューの有効性は、時間の経過とともに向上します。 これは、エラーの長期的なリスクが短期的なリスクよりもさらに低いことを意味します（エラーのリスクがゼロに等しいか非常に近い理由＃12を参照）。
理由＃15。 これは、本当に便利なレビューチェックリストを作成するのに最適な方法です。
まあ、それは少し疑わしいです、ユーザーのチェックリストは一般にユーザーにとってほとんど関心がありません（おそらく、「人工プレースホルダー」を説明するいくつかの理由を考え出すべきだったでしょう...ちょっと、正午の午後3時にツイートしました！）
理由16。 仮説：開発者が煩わしいエラーの修正に費やす時間が少ないため、スタッフの離職が少なくなります。
私は他の人がどのように働いているのかわかりませんが、私は仕事を続けました。他の点では、私が働いていたチームと周りの人々の質のため、それほどクールではありませんでした。 あなたがよく油を塗った機械の一部であるように感じることは素晴らしいことです。 これは、あなたが高品質の製品を生産し、あなたの同僚があなたをカバーするためにそこにいることを知って、あなたが毎日仕事に来るように動機付けします。
理由番号17。 製品の品質はプロジェクトの完了フェーズごとに向上するため、スケジュールから外れるリスクは減少します。
テスターはアイドル状態にならず（理由＃8を参照）、テストは引きずられません。 なぜなら スケジュールに対して十分な速さで応答が得られるため（理由＃1を参照）、テストにかかる時間を簡単に判断できます。
理由番号18。 ソースコードレベルでの（特に同僚からの）応答は、同じ間違いを何度も繰り返すのをやめることを意味します（理由＃6を参照）。
これは、各開発者が手にするエラーのタイプを手元に持っているため、これらのエラーを防ぐ方法を見つけることができるという事実に由来しています。 そして、これこそが魔法の本当の始まりです。つまり、あらゆる種類のミスを防ぐことを考え始めるときです。
理由19。 ドキュメント/コメントの品質とコード自体の改善。
（理由＃7を参照）開発者は、監査人からのより多くの質問に答えるのを避けるために、コードに対してより良いコメントをするでしょう。 監査人がコメントとコードの不一致を探す場合、これはドキュメントを最新の状態に保つための追加の動機です。 最終的には、非常に洗練されたコードが赤字になると思います。 通常のコードよりも何度も調査およびポーリングされます。
理由番号20。 ユーザーは、スープにいくつかのバグを見つけます。
この理由は、理由9に関連して不要に思えるかもしれませんが、ユーザーを支援することが作業のポイントですよね？ そのままにしておきます-上記で述べたように、リストに追加するいくつかの理由に取り組みます。
PSコード改訂ブログに移動しました。