私のチームでは、主要なコードレビューが隠蔽されていると考えています。コメントなしでマージされたコードレビューが多すぎます。

単一のコメントなしにコードレビューのようなものはないように思えます。

チームリーダーとして、チームが適切なコードレビュープロセスを行っていることを適切に監視し、プロセスのメリットを最大化するためにチームを支援するにはどうすればよいですか？

更新

人々はアップデートについて知りたいと思うかもしれません。ここで与えられた多くの提案を試みました。ほとんどはすでに使用されていました。一部は少し助けた。しかし、問題は残りました-私が見ていなかったときに、一部の人々は絶えず悪いコードを得ました。

コードレビューの監視は、チームツールを提供してコードを改善することほど有用ではないことがわかりました。

そこで、コピーペーストを検出するために「jscpd」という名前のライブラリを追加しました。コピーペーストでビルドが失敗しました。これにより、1つの問題がすぐに解消されました。

次に、codeclimateを試します。

また、半日スプリントで1回、古いコードレビューの手動レビューを行っています。私はtodosを問題/チケットに変換しています-人々がそれらを書いていることがわかりましたが、後で処理されることはありません。また、適切なときにコードをレビューするために、チーム全体と会議を行っています。

一般的に、正しい方向に進んでいるように感じます。

他の回答者とは異なるテイクを提供します。彼らは正しい-あなたが物事がどのように行くかを確認したい場合は関与してください。より多くのトレーサビリティが必要な場合、そのためのツールがあります。

しかし、私の経験では、何か他のことが起こっていると思います。

あなたのチームは、ほとんどのコミットに対してプロセスが壊れている/愚かな/効果がないと感じるかもしれないと考えましたか？プロセスは、従うべき規則ではなく、うまく機能するものを文書化していることを忘れないでください。そして、チームのリーダーとして、あなたは彼らがルールを執行するのではなく、彼らのベストになるように支援します。

そのため、レトロスペクティブ（アジャイルの場合）または1対1（マネージャーの場合）またはランダムな即席の廊下ミーティング（アジャイルでないチームリーダーで、他のマネージャーが1対1で行う場合） 。コードレビュープロセスについて人々がどう思うかを尋ねます。どのように機能しますか？どうですか？チームにできる限りの利益をもたらしていないと思います。必ず聞いてください。

これらの会議でコードレビューを支持することもできますが、フィードバックを聞く方が良いでしょう。最も適切なのは、「適切な」プロセスを調整する必要があるとチームが考えているか、何らかの根本的な原因（時間のプレッシャー、レビュー担当者の不足、ボブがコードをコミットしているために対処できない理由）があることです。 。

破損したプロセスの上にツールを強制しても、プロセスは改善されません。

私は1行の回答を投稿することを嫌いますが、これは適切なようです。

プロセスに参加します。

ReviewBoardやRedmineのcodereviewプラグインなどのツールを入手してください。次に、各レビューは、誰かによって閉じられるかコメントされる必要があるタスクとして作成されます（バグチケットのように）。その後、誰がレビューチケットを作成し、誰がそれをクローズしたかを追跡できます。レビューチケットをソースコードチェックインと結び付ける、つまり、リビジョンからチケットを作成できます。

いくつかのこと（正直なところ、これらのほとんどは回答全体にわたってカバーされていますが、私はそれらを単一の場所に置きたかったです）

• コードレビューが確実に行われるようにプロセスとルールを配置できますが、実際にコードレビューがボックスティックの練習以上のものになるようにそれらを配置することは非常に不可能です。最終的に、チームは、プロセスに有益にアプローチする場合、プロセスの利点を理解する必要があります。

• 例でリード。レビューに参加してください。開発者として、マネージャー（現在は開発者ではない）が私が見つけていないものを見つけたら、気分が悪いです。レビューでキャッチされるはずの問題を強調します（非難しない方法で）。生産上の問題が発生した場合、QA中に問題が発生した場合（別のQAプロセスがある場合）、コードレビューでそれらが検出された可能性がある場所を強調表示します。することができますどのようにチームと話し合う我々はそのような今後の課題がキャッチされていることを確認することができます

• チームがプロセスで何をしたいかを話し合います。（最初に発生する可能性がありますが）何らかの点が見当たらない場合は、本番の問題と必要な修正をその利点の証拠として使用します

• Sonarqubeのような自動化されたコードチェックソフトウェアを使用して、コードレビューが、理解できないコード、論理エラー、ドキュメントの欠如など、自動的に発見できない問題に集中できるようにします。

開発者と話し合って合意したコードレビューで、チームが望むものを文書化できます。コードレビューの一部として考慮することができるものは次のとおりです。

• コードが想定どおりに機能すること、つまり要件を満たしていることを確認します

• 開発者が一貫したスタイルにコーディングすることを保証するコードスタイル

• 最適化（関数呼び出しの数など）

• アーキテクチャと再利用性

• 例外処理とロギング

• 技術的負債：開発者が作業を開始したときよりも状態の良いコードです

• コードをチェックアウトしてビルドします（これは便利ですが、チームの他の開発者はこれをテスターに​​任せることを好みます）

• 自動化ツールを使用（SonarQubeを使用しました）。これをビルドプロセスに統合して、コードの改善を実施すること（テストカバレッジの向上など）が役立つと思います

上記の手順の一部は自動化されたツールでカバーできますが、コードのレビュー方法や改善方法を改善しようとしているときは、おそらくツールと眼球レビューの両方を使用する価値があります。ただし、技術的な負債（アーキテクチャと再利用性）を防ぐための最も重要な手順は完全に自動化することはできません。

あなたのチームがこれを適用することに一貫性がない場合、コードレビューを適切に実行している開発者にのみマージ権を許可することを試みることができます。たとえば、チームの主任開発者から始めたい場合があります。このアプローチとのトレードオフは、これらの開発者が開発プロセスのボトルネックになる可能性があるため、あなたとチームがこれを望むかどうかを決定する必要があるということです。個人的にはこのトレードオフを受け入れ、コードレビューを通じてチーム全体の規律を高め、準備ができたらマージ権を持つ開発者の数を増やすことができます。

最後に、レビューをレビューする価値があります。そのため、週に一度、開発者と協力して、レビューとそれらを改善する方法について建設的に話し合います。

私のチームがコードレビューをワークフローにすばやく統合した方法を説明します。

まず、質問させてください。バージョン管理システム（Mercurial、Gitなど）を使用していますか？

答えが「はい」の場合、次に進みます。

1. マスターブランチ（トランク）に誰もが（小さな修正であっても）何もプッシュすることを禁止します *
2. 別のブランチで新機能（または修正）を開発する
3. 開発者がブランチをマスターに統合する準備ができていると考えると、彼らは「プルリクエスト」を作成します
4. 誰もが自分のプルリクエストをマージすることを禁止します *
5. 別の開発者にプルリクエストを評価して、新しいコードをレビューしてもらう
6. コードがレビューに合格した場合、良い、プルリクエストをマージできます。そうでなければ修正を適用できます
7. コードが十分に成熟するまで手順6を繰り返します（最初からやり直すことなく実行できます）**
8. すべての新しいコードは、名前を持つ誰かによって（少なくとも要約的に）レビューされます

これで、コードレビューが行われるワークフローの正確なポイントができました。

そこに行動する。

*サーバー側のフックを使用して、自動的に実施できます

**この手順は（とりわけ）GitHubによって完全にサポートされており、かなり使いやすいので、チェックしてください。

テンプレートを作成し、チームメンバーにコードレビューを行うたびに更新するよう依頼する必要があると思います。ただし、その場合でも、最初にレビュープロセスに参加する必要があります。