コードレビューを効率的に監視する方法は？
私のチームでは主要なコードレビューが隠蔽されていると思います。コメントなしでマージされたコードレビューが多すぎます。
単一のコメントなしにコードレビューのようなものはないように私には思えます。
チームリーダーとして、チームが適切なコードレビュープロセスを行っていることを適切に監視するにはどうすればよいですか？また、プロセスのメリットを最大化するためにチームをどのように支援できますか？
更新
人々は更新について知りたいと思うかもしれません。私はここで与えられた多くの提案を試みました。ほとんどはすでに使用されていました。一部は少し助けました。しかし、問題は残りました-私が見ていなかったときに、一部の人々は継続的に悪いコードを受け取りました。
コードレビューの監視は、コードを最初から改善するためのツールをチームに提供するほどには役に立たないことがわかりました。
そこで、「jscpd」という名前のライブラリを追加して、コピーの貼り付けを検出しました。コピーペーストでビルドが失敗しました。これにより、1つの問題がすぐに解消されました。
次にcodeclimateを試してみましょう。
私はまた、半日のスプリントに1回、古いコードレビューの手動レビューを行っています。私はtodosを問題/チケットに変換しています-人々がそれらを書いていることを知ったので、それらは後で処理されることはありません。また、必要に応じてコードをレビューするためにチーム全体とのミーティングを行っています。
一般的に、私たちは正しい方向に進んでいるように感じます。
仲間の回答者とは異なる見方をするつもりです。彼らは正しい-あなたが物事がどのように行くのかを見たい場合は関与してください。もっとトレーサビリティが必要な場合は、そのためのツールがあります。
しかし、私の経験では、何か他のことが起こっているのではないかと思います。
あなたのチームは、ほとんどのコミットでプロセスが壊れている/愚か/効果がないと感じるかもしれないと考えましたか？覚えておいてください プロセスは何がうまく機能するかを文書化するものであり、従うべきルールを文書化するものではありません そして、チームがリードするとき、あなたは彼らが彼らの最高になるのを手助けするためにそこにいます、ルールを強制するのではありません。
振り返ってみると（アジャイルの場合）、1対1（マネージャーの場合）、またはランダムな即席の廊下の会議（非アジャイルのチームリーダーであり、他のマネージャーが1対1でやっている場合）の場合は、 。人々がコードレビュープロセスについてどう思うかを尋ねます。どのように機能していますか？いかがですか？チームに利益をもたらすことができなかったと思うとしましょう。必ずlistenしてください。
これらの会議でコードレビューを支持することもできますが、フィードバックを聞くことをお勧めします。最も可能性が高いのは、「適切な」プロセスを調整する必要があるとチームが考えるか、根本的な原因（時間のプレッシャー、レビュアーの不足、ボブが自分のコードをコミットするので、なぜできないのか）があるということです。 。
壊れたプロセスの上にツールを強制しても、プロセスは改善されません。
1行の回答を投稿するのは嫌いですが、これは適切なようです。
プロセスに参加します。
ReviewBoard または Redmineのcodereview プラグインなどのツールを入手します。次に、各レビューはタスクとして作成され、（バグチケットのように）クローズするか、誰かがコメントする必要があります。次に、誰がレビューチケットを作成し、誰がそれをクローズしたかを追跡できます。レビューチケットをソースコードのチェックインと関連付けることができます。つまり、リビジョンからチケットを作成できます。
開発者と話し合い、合意したコードレビューで、チームが何を望んでいるかを文書化できます。コードレビューの一部として考慮できるいくつかの点は次のとおりです。
コードが想定どおりの動作をすること、つまり要件を満たしていることを確認します
開発者が一貫したスタイルにコーディングできるようにするためのコードスタイル
最適化、例えば関数呼び出しの数
アーキテクチャと再利用性
例外処理とロギング
技術的負債：コードは、開発者が作業を開始したときよりも良い状態にあります
チェックアウトしてコードをビルドします（これは便利だと思いますが、私のチームの他の開発者はこれをテスターに任せたいと思っています）
自動化ツールの使用（私は SonarQube を使用しました）。これをビルドプロセスに統合して、コードの改善を実施すると便利です。テストカバレッジを増やす
上記の手順の一部は自動化ツールでカバーできますが、コードレビューの方法を改善したり実行したりする間は、ツールと眼球レビューの両方を使用する価値があります。ただし、技術的負債を防ぐための最も重要な手順（アーキテクチャと再利用性）を完全に自動化することはできません。
チームがこれを適用することに一貫性がない場合は、コードレビューを適切に実行している開発者にのみマージ権限を与えることを試みることができます。たとえば、チームのリード開発者から始めたい場合があります。このアプローチとのトレードオフは、それらの開発者が開発プロセスのボトルネックになる可能性があるため、あなたとチームはこれが必要かどうかを決定する必要があることです。個人的には私はこのトレードオフを受け入れ、コードレビューを通じてチームの他のメンバー全体の規律を高め、準備ができたらマージ権を持つ開発者の数を増やすことができます。
最後に、レビューをレビューする価値があります。週に一度、開発者と集まり、レビューとそれらを改善する方法について建設的に話し合います。
いくつかのこと（正直に言うと、これらのほとんどは回答全体でカバーされていますが、1か所にまとめたかったのです）
コードレビューを確実に行うためにプロセスとルールを配置することができますが、コードレビューを実際にボックスチェックの練習以上のものにするためにそれらを配置することはほとんど不可能です。最終的に、チームはプロセスの利点を確認する必要があります。
模範を示す。レビューに参加してください。開発者として、私のマネージャー（現在、非開発者）が私がしないものを見つけたら、私は気分が悪くなります。 （非難されない方法で）レビューでキャッチされるべきだった問題を強調表示します。プロダクションの問題が発生した場合、QA中に問題が発生した場合（別のQAプロセスがある場合）、コードレビューのどこに問題があったかを強調します。 weがそのような将来の問題を確実に捕捉できる方法をチームと話し合う
プロセスで何をしたいかをチームと話し合います。 （最初に発生する可能性があるように）彼らがそれへのポイントをまったく見当たらない場合、その利益の証拠として本番の問題と必要な修正を使用します。
Sonarqubeのような自動化されたコードチェックソフトウェアを使用して、コードレビューが、理解できないコード、論理エラー、ドキュメントの欠如など、自動的に特定できない問題に集中できるようにします。
私のチームがコードレビューをワークフローにどのようにすばやく統合したかを説明します。
まず、質問させてください。バージョン管理システム（Mercurial、Gitなど）を使用していますか？
答えが「はい」の場合、次に進みます。
- everybodyが何か（小さな修正であっても）をマスターブランチ（トランク）に直接プッシュすることを禁止する*
- 別のブランチで新機能（または修正）を開発する
- ブランチがマスターに統合される準備ができていると開発者が考えるとき、彼らは「プルリクエスト」を作成します
- everybodyが自分のプルリクエストをマージすることを禁止します*
- 別の開発者にプルリクエストの評価と新しいコードのレビューを依頼する
- コードがレビューに合格した場合は、プルリクエストをマージできます。そうでない場合は、修正を適用できます
- コードが十分に成熟するまでステップ6を繰り返します（最初からやり直すことなく実行できます）**
- 完了すると、すべての新しいコードが（少なくとも要約して）、名前を持つ誰かによってレビューされます
これで、コードレビューが行われるワークフローの正確なポイントが得られました。
そこで行動してください。
*サーバー側のフックを使用して、自動的に適用できます
**この手順は（とりわけ）GitHubによって完全にサポートされており、かなり簡単に使用できます チェックアウト