レビューするコードを選択するにはどうすればよいですか？

私は小さなソフトウェア会社の7人の開発者のチームの一員であり、定期的なグループコードとデザインレビューを紹介しようとしています。過去にいくつかのレビューを実施しましたが、散発的です。もっと定期的なものにしたいと思います。

私はコードコンプリートや他の類似のリソースを読んでいると、彼らはの力学について話どのようにコードレビューを実施することが、私は、選択する方法上の任意のベストプラクティスを見つけることができなかったものを確認することを。8年以上前のコードベースがあり、さまざまな言語をカバーしているので、見ることができるものがたくさんあります。

以下は、選択に影響を与える可能性のあるいくつかの要因です。

• 言語：C、Java、SQL、PL / SQL
• コード年齢：新しいコードと古いコード
• コードの使用：頻繁に使用されるコードと（効果的に）デッド/ほとんど使用されないコード
• コードの重要性：重要なコードと重要でないコード
• 開発者：ジュニア開発者コードとシニア開発者コード

これは絶対的な決定的な答えを伴う質問ではないことを理解していますが、ガイダンスがあれば役に立つでしょう。

周辺に関連するいくつかの質問：

• コードレビューのアプローチ（重要なセクションと新しい開発者コードをレビューするという意味）
• すべてのコードをレビューする必要がありますか？

一般に、すべてを確認する必要があります。新しいアプリケーションにLOCが2,000ある場合、すべてのLOCを確認する必要があります。

選択する方法には何のベストプラクティスが存在しない理由です何レビューには。

以前にレビューしたことのない既存の大規模なコードベースにアプローチする場合、既存の大規模なコードベースを書き直し、どこから開始するかを選択する必要がある場合も同じです。それは強く依存します：

• コードベース上（単一のモノリシックコードは、個別のコンポーネントセットなどよりも書き直し/レビューが難しい）

• あなたのコンテキスト（あなたが取り組んでいるすべてのものを止めて、書き換え/レビューだけに3ヶ月（3年？）費やすことができますか、それともあなたは自由な時間があるときだけ、わずかな時間でそれをしなければなりませんか？）

• 行うレビューのタイプ（レビューするもののチェックリストはありますか？チェックリストの項目によっては、最初にいくつかの部分をレビューすることもできます）。

もし私があなただったら、私は：

• リンクした2番目の質問の最初のコメントに記載されている80％〜20％の原則に従ってください。

• 100％は理想的であっても、それだけの価値はないと考えてください。単体テストの100％コードカバレッジのようなものですが、そのようなコードカバレッジはほとんど不可能または非常に高価です。

• 最も使用するコードの中で最も重要な部分から始めてください。ハッカーが行う前にセキュリティホールを確実に見つけたいので、コードベースに企業Webサイトの新しいユーザーを認証および登録するライブラリがある場合は、まずそれを確認します。

• 既存のメトリックを使用して、レビューする必要があるものを決定します。コードベースの一部にユニットテストがまったくない場合、同様に重要な別の部分のコードカバレッジが85％である場合は、最初の部分を確認することから始めます。コードベースの一部が、経験が浅く、同僚よりも多くのバグを導入することが知られている開発者によって作成された場合、最初にコードを確認することから始めます。

コードに加えたすべての変更を確認することから始めます。問題が悪化するのを防ぎます。次に、変更の頻度に基づいてコードのレビューを開始します。これらは「問題」領域になります。

コードのセクションをレビューしたことを追跡する何らかの方法を見つけて、コードのレビュー範囲を他の懸念事項と比較して分析できるようにします。

テストでカバーされていないコードを特定できる場合、レビューの優先度が高くなります。

本番環境に移行する前に行われたすべての新しい変更を確認します。インストールスクリプト、ソースコード、データベースの変更、すべて！コードレビューの全体的なポイントは、不良コードが実稼働に入るのを防ぐことです。貧弱な組織スキームであっても、何かが見逃されたために単に導入されたバグであっても。

作業中の現在のコードのリファクタリングは、コードレビューと連動します。たとえば、コードをレビューしているときに、バグ修正を含むクラスに重複したコードがあった場合、開発者が修正でそのコードを変更しなかったとしても、私はそれを渡しません。戻って重複コードを削除します。

リファクタリングを容赦なく行うと、コードレビューが役立ちます。そうでなければ時間の無駄です。

開発プロセスのステップとしてコードレビュープロセスを組み込むと、時間の経過とともにコードベースが改善されます。さらに良いのは、コードレビューのバックログが空になるまで、開発者が新機能の作業やバグ修正を行うことを許可しないことです。これにより、コードのレビューが確実に行われます。

リファクタリングが必要な既知の領域があるが、それらを行うのに長い時間がかかる場合（1週間以上）。次に、そのリファクタリング用のワークアイテムを単独で作成し、作業するアイテムとして追加します。

すべての新しいコード、および既存のコードへの変更を確認することから始めます。

既存のコードの変更を確認する場合、開発者はボーイスカウトルールに従う必要があります。彼が見つけたよりも良いコードを残してください。

それは、ファイル全体を完璧に修正する必要があるという意味ではありません。しかし、それは混乱に追加されるべきではなく、少し良くなるはずです。おそらく、適切に構造化された新しいクラスに変更を移動し、元のコードファイルの残りの部分をそのままにしておくことにより（結局、動作します）。

開発者として、すべての新しいコードと変更を確認してコードの改善を開始したら、アプリケーションのどの領域で最も変更が必要かを知っておく必要があります。次に、それらを確認し、少しずつ改善する方法について話し合います。

10年前に書かれたコードをレビューするためにレビューすることは無意味であり、開発者はこれらの10年間で改善するはずでした。だから、あなたが皆知っていることを学ぶためだけにそれをレビューする意味はありません。

コードレビューの目的は、現在行っている間違いを改善および修正し、その知識をチーム間で共有することです。

私のプロジェクトでは、開発中の割り当て/ユーザーストーリー/バグのほとんどの場合に必須のコードレビューを含めています。スクラム/アジャイルプロセスを使用しており、単体テストが記述されコードレビューが完了するまで、チケット/ストーリーはビルド（つまりQAのバックログ）に移動されません。

この目的のために、JIRA + SVNと統合されたCrucibleコードレビューでAtlassian FishEye分析を使用します。

開発者が特定のストーリーのコードをチェックインすると、FishEyeで新しいコードレビューを作成し、そこでチームの他のメンバーを選択してレビューを行います。

コードレビューが完了すると（ツールは送信された変更を強調表示し、特定のコード行にコメントを残すことができます）、開発者は言及された問題を修正/提案された改善を実装し、チケットをJIRAのBuilt列に移動します-つまり、ストーリーはテストする準備ができており、この特定の作業項目に必要なコード変更がこれ以上ないこと。

これにより、コードレビュー後にコードをリファクタリングする際に、QAが変更され、潜在的に破損する可能性のあるものをテストしないことも保証されます。

要約すると、すべてのコードをレビューする必要があります。これは、高品質のコードをサポートします。通常、コードの設計、可読性、保守性、テスト容易性が向上し、長期的には開発パフォーマンスが向上します。