一般的なコードレビュープロセスとは何ですか？

私の会社は最近、正式なコードレビューを開始しました。プロセスは次のようになります：githubに送信し、プルリクエストを要求し、約3人がコードをレビューし、すべてのパスが完了したらコードを入力します。

このプロセスは公平に思えますが、コードレビューを行う3人は公平ではないようです。レビューのためにコードを挿入すると、100〜200のコメントが表示されます。私にとって一番の数は一度300コメントでした。もちろん大きな変更だと思うでしょうが、これは50行未満のコード（ユニットテストを含む）でも非常に小さな変更になる可能性があります。すべてのコメントは「やらなければならない」と見なされ、議論はありません。

それを念頭に置いて、ここでの私の主な問題は、それが少し過剰に見えることです。私はグループと話をしましたが、彼らは基本的に、PHPで長年開発してきたからといって、「開発者」であるという意味ではないと言っていました。もちろん、これはそうでないことよりも痛いようです。また、グループ内ではあまりコメントを生成していないようであり、ほとんどの場合、他のコメントや提案を無視したり、無視したりします。

私の質問は、これが公平かどうかです。それとも普通ですか？

すべてのコメントは「やらなければならない」と見なされ、議論はありません。

それに優先順位がないので、それは本当の問題です私見。あなたは100から300件のコメントを取得すると、そこにする必要があり、それらのいくつかは、優先度A（実際のバグ）を有すること、それらのいくつかPRIO B（おそらく後にバグにつながる）およびそれらのいくつかは、C（他のすべてを）PRIO。すべての希望を尊重するが、変更を効果的にするために、そして時間を制限するために、優先順位付けを主張することを同僚に伝えてください。次に、prio Aのコメントを修正することから始めます。その後、本当に時間があれば、Bから始めることができます（運が良ければ、上司はprio BとCの修正はそれほど重要ではないことを理解し、時間を無駄にする代わりに、いくつかの重要なタスクを行います）。

コードレビューは分裂的なプロセスになる可能性があります。

しかし、あなたは重要な交差点にいます。レビューについて思慮深い分析を行います。彼らは、つまらない選択の問題を特定していますか、それともあなたのスタイルとロジックの重大な欠陥を強調していますか？

前者の場合、解決に向けて作業することをお勧めします（新しい仕事、または新しいコードレビュープロセス）。

後者の場合は、コードを専門的な品質に引き上げるために、多くのコード読み取りと調査を行うことをお勧めします。

あなたのコメントから、同僚がコードレビュープロセスを使用して方法論に同意するか、コードを洗練しているようです。私はあなたのようなコードレビューを始めたばかりで、時々実装アプローチや改善である事柄について多くのことを議論していることに気づきました。これは合理的な範囲ではまったく悪くありません（300件のコメントが多すぎるように見えますが、これはredditスレッドのように見えます）。

コードの実装を開始する前に、コードに関するアーキテクチャ上の決定に同意する必要がある場合もあれば、命名規則、パターン、およびグッドプラクティスについて同意しているだけで、「良いコード」と見なされるものをすべて知っている場合もあります。

あなたが言うようにコード標準に準拠しており、コードが意図したとおりに機能する場合、コメントはそれほど多くないはずなので、彼らはあなたのコードをフォーラムとして使っているか、あなたが指しているようにあなたをトローリングしています。

私は自分自身に批評をしようとし、会話に参加して、このコメントすべての理由を確認し、建設的な方法でそれについて話し、彼らがあなたのコードにどうしてそんなに不満なのか、そしてできるなら誰もが幸せになるような方法でコードを作成し、コードレビューで作業が滞らないようにします。

私はあなたの最後のコメントを読んでいます。時には、コードに同意しない場合は、100回それを超えて、あなたが幸せにならないあらゆる場所で変更を提案することができます。本当の理由は、あなたが別のアーキテクチャ上の決定をしたからですそして、あなたはそれを何度リファクタリングしても、そのコードが好きではないだけです。上記で述べたように、コードへのアプローチを事前に同意する必要があります。そうすれば、コードを記述するときに、コードから何を期待しているかがわかり、コードがより合理的になります。

あなたが言っていることから、彼らはPHP開発者に対してバイアスを持っているかもしれないので、彼らは彼らのポイントを証明するためにあなたのコードで間違っているものをすべて見つけようとしています。¹

コードレビュー自体については、すでに述べたように、このような膨大な量のマイナーなコメントは、いくつかの良い有効な批判よりも役に立たないと思います。また、コードレビューに関する経験は限られていますが、過去に働いていたチームにとって次の手法はうまく機能しました。

• まず、コードレビューを行う前に、静的コードアナライザーを使用してほとんどの問題を特定する必要があります。たとえば、Sonar、Lint、または他の優れたコードアナライザーを使用してコードを実行すると、ほとんどの小さな問題を取り除くことができます。特に、レビュー担当者がカスタムプロファイルを定義して、ブラケットの配置、空白、コメント、適切な変数の命名など、すべてを保証できるため...
• 第二に、コメントをさまざまなカテゴリに分ければうまくいくようです。たとえば、1つのグループに2つのカテゴリが含まれている場合、それらに注意し、将来適用する必要がある小さなものが含まれます。また、別のコミットとその後のレビューを必要とするコードの即時変更を必要とするコメントの2番目のグループ。もちろん、後者のグループのコメントの数は少なくする必要があります。

さらに、最初の実際のコードレビューには、当初予想していたよりも多くのコメントが含まれていたと言わざるを得ません。しかし、私はこれを悪いことだとは思っていませんでした。彼らのコメント²から学び続け、それらの新たに学んだテクニック/ベストプラクティスを将来のコード提出に喜んで適用するなら、コメントは少なくなるはずです。確かにそうだった;-)

¹ 私の経験では、多くのプログラマーがphpが最も邪悪なプログラミング言語であり、最も経験の浅いプログラマーがそれを使用していると主張しているため、これは頻繁に起こります。素晴らしいソフトウェアはどんな言語でも書けると信じているので、私はこの声明から距離を置いています！

² コメントは過剰ではあるが、ある程度の価値があると仮定する

コードレビューで定期的に100件以上のコメントを取得するのは一般的ですか？私は言わないと思います。コード品質が「多くのことを望まれている」人々が絶対に多くのコメントを得るのは一般的ですか？

ただし、コードレビュープロセスの「ルール」にも依存します。誰もが何かをする方法について独自のアイデアを持っています。コードレビュープロセスで「その方法ではなく、この方法で行うべき」という形式のコメントを許可している場合、適切なコードであってもコメントを大量に取得する可能性があります。プロセスが「欠陥」を見つけることを目的としている場合、コメントの数ははるかに少なくする必要があります。

私の経験では、代替方法の「提案」を許可するレビューは時間の浪費です。それらの「提案」は、レビュープロセスの外で1対1で処理する必要があります。欠陥レビューは、人々が「なぜ私がやったのと同じようにやらなかったのか」ではなく、バグに集中できるので、より便利です。誰かがバグを見つけたとしてもバグを否定することはないので、これはより便利です。したがって、傷ついた感情はありませんが、代わりに感謝の気持ちがあります。

更新：すべてのことを言っても、一部のコードは、欠陥がない場合でも、単純に悪いだけです。その場合、レビューのコメントは次のような単一のコメントでなければなりません。「このコードはクリーンアップする必要があります。コードが[あなたの名前]と話し合うまで、レビューを延期してください。」その場合、コメントが修正されるまでコードのさらなるレビューを停止する必要があります。

UPDATE2：@User：開発中にコード/デザインについて話し合って、自分のやり方でやり遂げる前に彼らが探しているものを実装できるようにしますか？提案に基づいてコードを開発する方法について何か変更したり、自分のやり方は問題ないと思っていますか？彼らのコメントから何か学んでいますか？

私がプロジェクトのswリードであるとき、すべての作業成果物を担当することは私の仕事です。作業成果物を承認すると、その成果物は受け入れられると主張します。高品質の製品を構築することで評判を得たいです。したがって、私は期待を抱いており、満足のいくものを受け入れません。同時に、自分の好みの理由を教えて説明しようとしています。これらの好みは常に理想的であるとは限りません（特に他の人の目には）が、それらの好みのほとんどは経験から来ています。通常、悪いものを繰り返すことを避けるための反応。したがって、プッシュバックに関係なく、私の承認を得るために必要な私の個人的な「スティックラー」がいくつかあります。

一方、作業成果物を承認するために必要な期待を学ぶ必要があります。あなたは反対することができますが、あなたは支配する権限を持っているようには見えないので、期待されることを学びます。チームがあなたを失敗させようとしているとは思わない。そのため、それらも見た目が悪くなります。その点で、あなたが（そうでないとしても）学びたいと熱望していることを示すだけで、彼らの言うことを聞き、彼らの好みに適応するために最善を尽くします。少なくとも許容できるものを見つけて、彼らがあなたのやり方を教えるために少し手をつないでくれるかどうかを確認するかもしれません。誰が知っているか、その過程であなたは本当にあなたのスキルを次のレベルに引き上げることができる何かを学ぶかもしれません。

チームの検査プロセスとの重要な違い：

• 検査の基礎は、チーム全体がまとめたチェックリストです。
• 焦点は欠陥（現在と未来）であり、スタイルのためのスタイルではありません。
• 3人の検査官（著者を含む）が一緒に座ってコメントを実行します。多数決のコメントのみが残ります。

50 LOC 300のコメントについては少し過剰なようです-プルリクエストごとに3人のレビュアーがいますか？会社には多くのリソースが必要です。

有用なコードレビュープロセスに関する私の経験から、いくつかのルールやガイドラインが必要です。

• コメントの優先度
• コメントの分類（バグ、コードスタイルなど）
• 合意されたアーキテクチャ/従うべき設計
• 合意されたコードスタイル

レビュアーから優先順位が得られない場合は、担当のプロジェクトマネージャー/チームリーダーに問い合わせてください。コストの責任者は、優先順位について意見を持つ必要があります。

定義済みのアーキテクチャ、プロジェクトで使用するデザインパターンの共通理解、および合意されたコードスタイルがある場合、レビューコメントは、セキュリティ問題、意図しないバグ、指定されていないコーナーケースなどの「実際の問題」についてのみである必要があります建築など

開発チームが「味の問題」に同意していない場合（たとえば、メンバー変数が「m_」で始まる場合）、すべてのレビュアーは自分のスタイルに従うように強制します。これは時間とお金の無駄です。

これはコミュニケーションの問題のように思えます。あなたのコードは300コメントに値するほど悪くないという期待があります。レビュー担当者は、多くのフィードバックが必要だと考えているようです。非同期の方法で行ったり来たりすることは、多くの時間を無駄にします。ヘック、300件のコメントを書くのは時間の無駄です。これらがすべて欠陥ではない場合、新しいチームメンバーとして、チームのスタイルがまだわからない可能性があります。それは正常なことであり、チーム全体を加速するために学ぶべきことです。

私の提案は時間を節約することです。フィードバックを加速します。私は...するだろう：

• 同じ間違いをして同じコメントを50回生成しないように、中間レビューをさらに行う
• レビュアーがコードをレビューするときに座って、問題が発生したときに話し合うことができるため、次のコミットで消去される300の「問題」を文書化する必要がなくなります。
• これらの「本物の」開発者の1人としばらくの間コードを書いて、彼らがどう違うかを見てみましょう

「時間がかかる」ため、ペアリングに反対する人もいますが、ここでは明らかに問題ではありません。