コードレビューは良いことだと上司を説得するためのヒント
たとえば、プロジェクトに共同で作業することがほとんどない複数の開発者がいる架空の会社で働いているとします。ボスは、コードレビューが時間とコストに見合う価値があるとは考えていませんでした。
このシナリオで提示される可能性のある、コードレビューの利点を表すさまざまな引数は何ですか。さらに、ここでのコードレビューに対する潜在的な議論は何ですか？これらはどのように対抗できますか？
このような基本的なことを正当化する必要がある場合は、より大きな問題が発生します。
あなたはエキスパートであり、あなたのチームはあなたが使用するプラクティスを決定する必要があります。たぶん、あなたは上司にその非常に重要な原則を説得し始める必要があります。
上司は[〜＃〜] what [〜＃〜]を決定することになっており、さらに重要なのは[〜＃〜] why [〜＃〜]決定することです。 [〜＃〜] how [〜＃〜]ビルドする必要があります
（それはもちろん、会社で何を、なぜ行うのかを提案できないという意味ではありません）。優れた上司は、従業員に企業戦略への参加を奨励する必要があります）
しかし、ここに私がピアコードレビューを表示する方法があります：
プログラミングは非常に集中的な知的作業であるため、一人ですべてが完璧であることを保証することはできません。したがって、コードレビューでは次のことを確認します。
- アプリの出荷前に脆弱性またはバグが見つかりました
- 開発者間の一定の相互教育（ほぼ無料）が達成されます
- アプリのメンテナンスを容易にするためのコード尊重基準
- コードは要件に一致
誰もが直接メリットを享受しています：
- 知識を増やし、チームメイトに自分の知識を渡すことができる開発者
- バグが少なく、メンテナンスに費やす時間が少ない顧客/ユーザー
- 顧客/ユーザーの満足度が高く、トレーニングに費やす時間が少ないボス
コードレビューにより、複数の開発者が同じコードに慣れることができます。これは良いことです。元の作者がやめようと決めた場合、さらに悪いことに、彼に何か悪いことが起こります。コードレビューが定期的に行われる場合、他の人がすぐに引き継ぐことができます。
ピアは、コードレビュー中に潜在的なバグやパフォーマンスの問題を発見できる可能性があります。これにより、QAと開発作業が軽減されます。これにより、コードレビューに伴う追加コストを補うことができます。
コードレビューは知識の共有を促進します。ピアは、より良い方法または別の方法で別の方法を教えてくれます。私自身も、コードレビューを通じて仲間から多くのことを学びました。
コードレビューは、チームが従うコーディングガイドラインを強化するのに役立ちます。チームにない場合は、修正する必要があります。コードは、1回記述して何度も読み取ることを目的としています。コーディングのガイドラインは、コードを読みやすくするためのステップです。コードは、ピアが読み取れるようになっています。読みやすさを確保するためにコードレビューを行うよりも良い方法は何ですか？
ここにたくさんの素晴らしい答えがあります。追加するいくつかのこと：
コードを他の人に説明する必要がある場合、多くの場合、説明の過程で開発者は彼がバグを持っていることに突然気づくことがあります。レビューアーがバグを確認するのに十分なことを理解する前に、開発者が彼のトラックで死んで停止し、「それは間違っている」.
コードが他の人によって検査されることを知っていると、コーディング標準を使用する（メンテナンスが容易になる）か、自分以外の誰も（時には自分も）理解できない「カウボーイ」メソッドを使用するインセンティブが高まります。他の人にコードを見せても恥ずかしがりたくないので、そもそもコードを上手に活用します。恥ずかしさのために、「なぜこれが機能するのかはわかりませんが、いじりません」というコメントの付いたコードはほとんど残っていません。コードベースで。
より広範な監督またはトレーニングが必要な開発者は、簡単に特定できます。完全に無能です。パフォーマンスの問題を見つけて対処するのが早ければ早いほど、チーム全体の利益が向上し、アプリケーションの品質が高くなります。トレーニングが必要な新人を採用する前に、この情報を見つけて、アプリケーションの最も困難で最も重要な部分に割り当てることをお勧めします。
時々それは他の多くの場所で同じ間違いをすることを救うだろう誤解を正すことだけの問題です。たとえば、最近いくつかのSQLで複雑なレポートを確認したところ、新しい開発者の何人かが、データベース内の特定の情報をどこに見つけるかについて誤解していることがわかりました（確かに、選択した場所は論理的なものであり、これはデータベース設計の問題です）また、修正する必要があります）すべてのレポートを正しく作成することが重要です。彼らが書いた最初のレポートで問題を見つけて修正することで、残りのレポートで同じエラーが発生するのを防ぎました。そして、年をとった（ここでは時間ではなく働いている）開発者は、説明が必要だとは思わないほど慣れていました。また、新しい開発者が最新の状態にあることを確認するためにおそらく必要なものが他にもあることに気づきました。
ジュニアは、上級者（たとえば、エラートラップやEdgeケースをよりよく理解する傾向がある）によって書かれたより洗練されたコードから学ぶことができ、上級者は、未経験のジュニアが使用する新しいテクニックから学ぶことができます。
アプリケーションの異なるが関連する部分に取り組んでいる人は、2つの異なる相互に排他的な方向に進んでいることに気付く場合があります。おっと、修正が簡単になりました。
ハードコードされた値をこっそりと取得するのは簡単ではありません。これは、物事を今すぐに機能させるために、時間の経過とともに変化します。これにより、会計年度の初めに変更されるような将来の多くのバグを防ぎます。
私は時々何かをする方法に行き詰まり、他の誰かのものをレビューするコードから私が欲しかっただけの新しいテクニックを学びました。
チームの他のメンバーの考え方に精通している場合（どのコードレビューがその理解に役立つか）、Joeがどのようにそのようなアプローチをしたかを理解することから始めるので、後で問題をトラブルシューティングするのが簡単になります。問題。
他の人が言及した知識の共有と同様に、コードレビュー中に発見されたであろうバグの例を見つけ、修正にかかった時間を測定します。これには、問題の調査とパッチバージョンのリリースに費やされた時間と、バグを修正する実際の時間。
このコストは、少なくとも数日かかると考えられ、コードのレビューと結果の処理に費やした時間とは対照的です。
これは、コードレビューが費用に値することを上司に示します。
コードレビューでできること：
- 共有できるコードライブラリの開発につながる
- 変数、定数、データベーステーブルに統一された命名規則を提供する
- プロセスの合理化を支援
- 発見プロセスと要件収集のレビューにもつながります
- アプリケーションのアドオンとして販売できるウィジェットの開発につながります。 （それを実装するたびに一度支払われるビルド）
- 新製品につながる
短所
- そのための時間はありません
それが本当なら、どうして私たちはいつも同じ顧客に対して2〜3回物事を行う時間を持っているように見えますが、最初にそれを正しく行うための十分な時間がありません。
Steve McconnelのConstruxから より優れたソフトウェアプラクティスのビジネスケース および ソフトウェアソフトウェア開発の低ぶら下がり果物 （LHF）がこれに対処します。後者の「上級管理職に抵抗されないLHF」には、検査がリストされています。
発表するときは、全体像に焦点を当ててください。
メリット（コードの改善、バグの減少、再書き込みの減少など）をリストし、コードレビューをoneとして、推奨するテクニックとして言及します。
私はそれをソフトウェアの職人技を行うより大きな絵の一部にします
- コードレビュー
- テスト
- 回顧
- 知識共有
- 教育
- 書評
- ランチタイム講義
これらの原則を推進するために、自分で多くの作業を行う準備をしてください。
ほとんどの場合、説得が「1回の会議で行われる」とは思われません。
落ち着いて、一貫して、時間をかけてケースを作成する必要があります。より良いテクニックで修正されたであろうバグに最も悩まされているときは、感情的になりすぎて合理的ではなくなる可能性が高くなるため、多くの場合、ケースを作るのに最悪のタイミングです。これは多少直観に反するように見えるかもしれませんが、私が30年以上のプログラミングで学んだことです。明らかにymmv。
ドキュメントを参照する必要がある場合は、尊敬される「コードコンプリート」以外は探しません。その中で、本はユニットテスト対ピアレビューでどれだけ多くのエラーがキャッチされるかを説明しています。それは驚くべきことです。単体テストでは、メモリが適切である場合、すべてのバグの30％しかキャッチしませんが、正式なピアレビューでは70％をキャッチします。
その情報を受け取り、本で彼を示し、彼の財政面に訴えます。バグを早期に発見するよりも、バグを許可する方がはるかに時間がかかり、はるかにコストがかかります。