強制的なコードレビューの適切なガイドラインと実践[終了]

コミットごとに必須のコードレビューを試行しています。作成者ではなく、少なくとも1人が検証していないマスターは何もありません。開発者と管理者の両方から賛同を得ています（これは驚くべき状況です）。

• 明らかなバグの削減
• プロジェクトの周りで起こっている変化についてのより多くの認識
• 「誰かがこれを見て、怠けないようにする」/反カウボーイ効果
• プロジェクト内/プロジェクト間の一貫性の向上

しかし、速度を低下させることが知られているものを導入しており、間違ってやるとコミットパイプラインに愚かな官僚的なステップができてしまい、時間がかかります。私が心配していること：

• 単なるピッキングに発展するレビュー
• （双曲線的に）2行のコミットレビューの一環として、巨大なアーキテクチャの問題を公開する人々。
• 答えに他のことを偏らせたくありません。

私たちはすべて合理的な人であり、多くの自己分析を行っていますが、レビューセッションで実際にどのようなことを達成しようとしているかについて、戦いで得た洞察を間違いなく使用して、レビューを実際に機能させることができます。動作することがわかっているガイドラインとポリシーは何ですか？

1. レビューを短くします。

   特にコードレビュー中は、長時間集中することは困難です。さらに、長いコードレビューは、コードについて語るには多すぎること（次の2つのポイントを参照）、またはレビューがアーキテクチャなどのより大きな問題に関する議論になることを示す場合があります。

   また、レビューはディスカッションではなくレビューのままにしてください。コードの作者が返信できないという意味ではありませんが、長い意見交換になってはいけません。

2. あまりにも悪いコードのレビューは避けてください。

   低品質のコードをレビューすることは、レビュー担当者とコードの著者の両方にとって憂鬱です。コードがひどい場合、コードのレビューは役に立ちません。代わりに、作成者にコードを正しく書き換えるように依頼する必要があります。

3. レビューの前に自動チェッカーを使用してください。

   自動チェッカーは、自動的に検出される可能性のある貴重な時間指定ミスを無駄にしません。たとえば、C＃コードの場合、StyleCop、コードメトリック、特にコード分析を実行すると、レビュー前にいくつかのエラーを見つけることができます。次に、コードのレビューは、マシンにとって非常に困難なポイントに費やされる場合があります。

4. レビューを行う人を慎重に選択してください。

   互いに耐えられない2人は、別のコードの1つを適切にレビューしません。同じ問題は、ある人が他の人を尊重しない場合にも発生します（ちなみに、それが校閲者であろうと著者であろうと）。

   また、一部の人はコードのレビューを見ることができないため、批判されておらず、ネガティブなものと見なすべきではないことを理解するには、特別なトレーニングと準備が必要です。準備ができていないレビューを行うことは、常に防御的であり、コードの批評家に耳を傾けないため（すべての提案を批判と見なす）、助けにはなりません。

5. 非公式と正式の両方のレビューを行います。

   チェックリストがあると、欠陥の正確なセットに集中するのに役立ち、nit pickingに陥ることを回避できます。このチェックリストには、次のようなポイントを含めることができます。

   • SQLインジェクション、
   • エラーにつながる可能性のある言語に関する誤った仮定、
   • オペレーターの優先順位など、エラーにつながる可能性のある特定の状況。たとえば、C＃では、var a = b ?? 0 + c ?? 0;合体がゼロの2つのNULL可能数を追加したいが、そうではない人には見栄えがするかもしれません。
   • メモリの割り当て解除、
   • 遅延読み込み（2つのリスク：同じものを複数回読み込み、まったく読み込まない）
   • オーバーフロー、
   • データ構造（たとえば、ハッシュセットではなく単純なリストなどのエラーを含む）、
   • 一般に、入力の検証と防御的なプログラミング、
   • スレッドセーフティ、
   • 等

   ここでリストを停止しますが、正確な著者の弱点に応じて、チェックリストに含まれる可能性のある数百のポイントがあります。

6. チェックリストを徐々に調整します。

   時間の経過とともに建設的で有用な状態を保つために、正式なレビューで使用されるチェックリストは、発見された間違いに応じて時間をかけて調整する必要があります。たとえば、最初の非公式レビューでは、SQLインジェクションのリスクがある程度明らかになる場合があります。SQLインジェクションチェックはチェックリストに含まれます。数ヶ月後、著者が動的なクエリとパラメータ化されたクエリに非常に注意しているように見える場合、SQLインジェクションはチェックリストから削除される可能性があります。

ほとんどチェックリストがあります：

• タスクの説明を表示します。
• 結果を説明し、動作することを示します。さまざまなシナリオ（無効な入力など）を実行します。
• 合格したテストを表示します。テストカバレッジはどのようなものですか？
• コードを見せてください-私たちは明らかに非効率を探しています。

かなりうまくいきます。

他の人よりも権力のある人であれば、管理者またはモデレーターで無関係なコメントをカットし、迅速なレビューが必要なもののレビューをスピードアップするのに十分だと思います。単一の意思決定者。

これのマイナスは、この人が主なタスクとしてそれをしなければならないということです、彼は何か他のことをしているかもしれません、そしておそらくあなたはこのポジションで最も経験豊かな人になりたいでしょう。

2つ目は、できる限り自動化することです！

• 空白の制御
• スタイル制御ソフトウェア
• コードレビュー前の自動ビルド
• コードレビュー前の自動テスト

これらのことは、人々が本当の必要なしにコメントするかもしれない少なくともいくつかのものを削除します。ビルドされていないか、末尾に空白がある場合は、レビューに十分ではないので、修正して、再度レビューを申請してください。それが構築されていないか、いくつかのテストが失敗した場合、それは十分ではないことは明らかです。

それの多くはあなたの技術に依存しますが、自動的にチェックできるものをより良く見つけてください。

私たちはまだこの戦いに勝っていませんが、それが有用であることがわかりました。