すべてのプログラマーが確率論に精通しているわけではありません。 それは見えるだろう-さて、問題は何ですか？ 誰が何を研究したか、普遍的な天才はいない。 理論的には、ゲーム開発、暗号化、金融ソフトウェア、統計ソフトウェアのいずれでも可能であることを除けば、知っておく必要があります。 しかし、違います！ いくつかのことを誤解すると、そのアプリケーションが臭いを感じないプロジェクトでも、悪い結果につながる可能性があります。 魔法はありません。人間の脳だけがいくつかの確率を誤って推定し、その結果、間違った決定を下します。
だから、あるプログラマーVasyaを想像してください。 彼はコードを書きます。 彼はプログラマーだからです。 Vasyaが優れたプログラマであり、彼のコードの75％にエラーがないと仮定します。 実際、私はもちろん嘘をつきます、そして、Vasyaがそのような教祖であるということはありそうにないです、しかし、再び想像してください。 簡単にするために、コードの100行ごとに、75は修正を必要とせず、25のエラーを見つけて修正する必要があると想定しています。 そして、私たちはそれをどうするかを決定します。 いつものように、多くの意見があります。ユニットテスト、QA部門の拡大、各コミットのコードレビュー、すべてを一度に予算と期限を無視する完璧主義者、自信のある「長所」と貪欲なマネージャー一度に。 まあ、いつものように。 しかし、何かを決定する必要があります。 そして、各タイプのアクティビティのリソースとその利益を評価するというアイデアがあります。 次に、コードレビューなどの効率を評価しましょう。
経験の浅い計算は次のようになります。Vasyaは100行のコードを記述しましたが、通常は正しいコードの約75％、バグの25％を持っています。 コードレビューに同じ時間を費やしてもらい、バグを2倍減らします（12.5％）。 さて、2倍のリソースが消費されるため、バグが2倍少なくなります。
しかし、そのようなものは何もありません！ VasyaはVasyaです。 彼は昨日このコードを書いた。そして彼が今日彼のコードのコードレビューを行うならば、彼は何も見つけられないだろう。 なんで？ なぜなら。
大丈夫。 そのため、Petya（ほぼ同じ資格の）が自分のコードを見ると、彼はバグの数を半分（12.5％に）減らします。 なぜなら、彼らはほぼ同じ資格ですが、それでも人が異なるからです。そして、この作業に2倍のリソースを費やすことがわかります。つまり、バグが2倍少なくなります。 それでは、それが実際にどのようであるかを見てみましょう。
確率論によれば、信頼性がXとYの2つのデバイスのシステムがあり、それが故障するためには両方のデバイスが故障しなければならない場合、システムの全体的な信頼性は1-（1-X）*（1-Y）です。 つまり 75％の同じ信頼性を持つ「デバイス」VasyaとPetyaの場合、全体的な信頼性は93.75％になります。 バグの数は12.5％ではなく、6.25％に減少しました。 つまり 同様の資格であっても他の人のリソースをコードレビューに費やしたため、バグの数は半分ではなく、4倍に減少しました！ かっこいい。 さらに、通常、コードレビューはチームの最高の開発者（大まかに言って、「平均」75％より高い信頼性を持っている）によって行われ、作成者がコードを書くよりもはるかに少ない時間しか費やさないため、さらに印象的な結果が得られます。
なんで？
コードレビューに一定量のリソースを投資することで何が得られるかをよりよく理解できるようになったので、コードの品質を改善するためにこのメカニズムや他のメカニズムを適用するかどうかをより簡単に決定できます。 実証されていない「誰もがそれを行うのは正しい」とではなく、数字で操作することができます。 適切なガイダンスを得るために、数字でサポートされている議論は、単に大声でフレーズを投げるよりも常に重要です。
記事全体を読むのが面倒な人のための短い結論
Code Reviewを使用すると（まだ使用していない場合）、最初に考えている以上に役立ちます。