回答:
このような基本的なことを正当化する必要がある場合、より大きな問題があります。
あなたはエキスパートであり、あなたのチームはあなたがどのプラクティスを使用するかを決めるべきです。たぶん、あなたは上司にその非常に重要な原則を納得させるべきでしょう。
あなたの上司が決めることになっているWHATさらに重要なことやるとするなぜそれをやって。あなたはの世話をする必要がありますどのようにビルドそれ
（それはもちろん、あなたの会社で何を、なぜ行うのかを提案できないという意味ではありません）。優秀な上司は、従業員に企業戦略への参加を奨励する必要があります）
ただし、ここにピアコードレビューを表示する方法を示します。
プログラミングは非常に集中的な知的作業であるため、一人がすべてが完璧であることを保証することはできません。そのため、コードレビューでは次のことを確認します。
誰もが直接利益を享受しています：
コードレビューにより、複数の開発者が同じコードに精通することができます。これは良いことです。原作者が辞職するか、さらに悪いことに決めた場合、彼に何か悪いことが起こります。コードレビューが定期的に行われると、他の人がすぐに引き継ぐことができます。
ピアは、コードレビュー中に潜在的なバグやパフォーマンスの問題を発見できる可能性があります。これにより、QAと開発の労力が削減されます。これにより、コードレビューに伴う追加コストを補うことができます。
コードレビューは知識の共有を促進します。仲間は、より良い方法や、物事を行う別の方法を知ることができます。私自身もコードレビューを通じて仲間から多くを学びました。
コードレビューは、チームが従うコーディングガイドラインの強化に役立ちます。チームに1つもなければ、それを修正する必要があります。コードは、一度書くだけで何度も読むことを意図しています。コーディングのガイドラインは、読み取り可能なコードへの一歩です。コードは、ピアが読めるようになっています。読みやすさを確保するためにコードレビューを行うよりも良い方法はありますか？
ここにはたくさんの素晴らしい答えがあります。私が追加するもの：
コードを他の誰かに説明しなければならないとき、多くの場合、説明の過程で開発者は突然バグがあることに気付くかもしれません。レビュー担当者がバグを理解するのに十分なことを理解する前に、開発者が彼のトラックで死んで停止し、「間違っているのを待ってください」と言うことが何度も起こります。
自分のコードが他の誰かによって検査されることを知っていると、コーディング標準を使用する（メンテナンスを容易にする）インセンティブが得られます。コードを他の人に見せたときに恥ずかしい思いをしたくないので、そもそもより良い仕事をします。恥ずかしい要素のため、「これがなぜ機能するのかはわかりませんが、それを台無しにしないでください」とコメントされるコードは少なくなります。コードベースで。
より広範な監督やトレーニングが必要な開発者は簡単に特定できます。まったく無能な人もいます。パフォーマンスの問題をより早く見つけて対処できるほど、チーム全体のパフォーマンスが向上し、アプリケーションの品質が向上します。トレーニングを必要とする新しい人を連れて、アプリケーションの最も難しい、最も重要な部分に彼を割り当てる前に、この情報を見つけることは良いことです。
他の場所で同じ間違いをするのを防ぐ誤解を修正するだけの場合もあります。たとえば、最近、いくつかのSQLで複雑なレポートを確認しましたが、新しい開発者の中には、データベース内の特定の情報をどこで見つけるかについて同じ誤解を抱いていることがわかりました（確かに、選択した場所は論理的であり、データベース設計の問題でしたまた、修正する必要があります）、すべてのレポートを正しく作成するために重要です。彼らが書いた最初のレポートで問題を見つけて修正することで、残りのレポートで同じエラーが発生するのを防ぎました。そして、（年齢ではなくここで働いている）年配の開発者が慣れていたので、説明する必要がないと思いました。
ジュニアは（たとえばエラートラップやエッジケースをよりよく理解する傾向がある）シニアが書いたより洗練されたコードから学ぶことができ、シニアはまだ経験していないジュニアが使用する新しいテクニックから学ぶことができます。
アプリケーションの異なるが関連する部分で作業する人々は、2つの異なる相互排他的な方向に進んでいることに気付くことがあります。簡単に修正できるようになりました。
現在動作するようにするためだけに時間とともに変化するハードコードされた値を盗み出すことはそれほど簡単ではありません。これにより、各会計年度の初めに変化するものなど、将来の多くのバグを防ぎます。
私は時々、何かをする方法にこだわって、他の人のものをレビューするコードからちょうど望んでいた新しいテクニックを学びました。
チームの他のメンバーの考え方に精通している場合（どのコードレビューがその理解に役立つか）、ジョーがその種のアプローチにどのようにアプローチするかを理解することから始めるため、後で問題をトラブルシューティングするのが簡単になります。問題。
コードレビューの可能性：
短所
それが本当なら、どうして同じ顧客のために2、3回物事をする時間がいつもあるように見えますが、最初にそれをするのに十分な時間がありません。
コードレビューを使用するチームと実行しないチームの2つのチームが並行して実行するデモ（1週間の「ミッキーマウス」型プロジェクト）を実行してみてください。
週の終わりに、各チームの仕事の質を評価すると、コードレビュー担当者がより良い結果になると確信しています。
Steve McconnelのConstrux より、より優れたソフトウェアプラクティスのビジネスケースとソフトウェアソフトウェア開発の低吊り果物（LHF）がこれに対処しています。後者からは、「上級管理職に抵抗されないLHF」が検査をリストしています。
それを提示するときは、全体像に注目してください。
利点（より良いコード、より少ないバグ、より少ない書き換えなど）をリストし、推奨する手法の1つとしてコードレビューに言及します。
私はそれをソフトウェアの職人技の全体像の一部にしたいと思います
これらの原則を促進する上で、多くの作業を自分で行う準備をしてください。
ほとんどの人は、説得が「1回の会議と完了」のようなものであるとは考えていません。
落ち着いて一貫してケースを構築してください。優れた技術によって修正されたバグに最も悩まされているときは、過度に感情的で合理的ではない可能性が高いため、ケースを作るのに最悪の場合がよくあります。これはやや反直感的なように思えるかもしれませんが、30年以上のプログラミングで学んだことです。明らかにymmv。