一般的なコードレビュープロセスとは何ですか？
私の会社は最近、正式なコードレビューを開始しました。プロセスは次のようになります。githubに送信し、プルリクエストをリクエストし、コードが約3人でレビューされ、すべてが合格した場合、コードが入力されます。
プロセスは公平に見えますが、コードレビューを行う3人は公平ではないようです。コードをレビューのために配置すると、100〜200のコメントが表示されることに気づきました。私のトップの数は一度300コメントだった。もちろん、それは大きな変更だと思いますが、これは非常に小さな変更で、50行未満のコード（単体テストを含む）である場合もあります。すべてのコメントは「しなければならない」と見なされ、議論はありません。
それを念頭に置いて、ここでの私の主な問題は、それが少し過剰に見えることです。私はグループと話しました、そして彼らは基本的に私がphpで非常に長い年の開発をしたからといって、私が「開発者」であるとは限らないことを私に言いました。もちろん、これはもっと害があるようです。また、グループ内ではコメントがあまり多くないようで、ほとんどの場合、他のコメントを無視したり無視したりして、何かが壊れていても、それを有効なポイントとして受け入れることはめったにありません。
だから私の質問は、これが公正かどうかです。または一般的ですか？
すべてのコメントは「しなければならない」と見なされ、議論はありません。
IMHOそれは本当の問題です、なぜならそれには優先順位がないからです。 100-300件のコメントを取得すると、必須優先順位A（実際のバグ）の一部、優先順位B（後でバグにつながる可能性が高い）の優先順位、および優先順位C（ほかのすべて）。すべての希望を尊重し、変更を効果的に行い、時間は限られていることを同僚に伝え、優先順位を主張します。次に、最初にプリオAのコメントを修正することから始めます。その後、さらに時間がある場合は、Bから始めることができます（運が良ければ、上司はプリオBとCを修正しないことを理解しますso重要であり、時間を無駄にする代わりに、より重要なタスクをいくつか提供します）。
コードレビューは分裂的なプロセスになる場合があります。
しかし、あなたは重要な分岐点にいます。レビューを慎重に分析します。彼らは一瞬を選ぶ問題を特定していますか、それともあなたのスタイルとロジックの深刻な欠陥を強調していますか？
前者の場合は、解決に向けて取り組むことをお勧めします（新しいジョブ、または新しいコードレビュープロセス）。
後者の場合は、コードをプロの品質に引き上げるために、多くのコード読み取りと学習を行うことをお勧めします。
あなたのコメントでは、同僚がコードレビュープロセスを使用して、方法論に同意したり、コードを磨いたりしているようです。私はあなたと同じようにコードレビューを始めたばかりで、実装のアプローチや改善だけのことについて時々議論することに気づきました。これは、その妥当な範囲ではまったく悪くありません（300のコメントは私には多すぎて、redditスレッドのように見えるに違いありません）。
コードの実装を開始する前に、コードに関するアーキテクチャ上の決定に同意する必要がある場合や、命名規則、パターン、および推奨事項に同意して、「良いコード」と見なされるものをすべて知っている場合があります。
あなたが言うようにコード標準に準拠していて、コードが意図したとおりに機能している場合、コメントはそれほど多くないはずです。そのため、彼らはコードをフォーラムとして使用している、または指さしているようにあなたを荒らしています。
私は自分自身に対して批評家になるように努め、会話に参加し、このすべてのコメントの理由を確認し、建設的な方法で彼らと話し合い、なぜ彼らがあなたのコードにそれほど不満であるか、そしてあなたができるかどうかを確認しますみんなを幸せにし、コードレビューで作業が行き詰まらないような方法でコードを記述してください。
私はあなたの最後のコメントを読んだだけですが、コードに同意しない場合は、それを何回も調べて、満足できないような変更を提案することができます。本当の理由は、異なるアーキテクチャの決定をしたことになるからです。そして、何回リファクタリングしても、そのコードが気に入らないだけです。上で述べたように、コードへのアプローチに事前に同意する必要があるかもしれません。そうすることで、コードを書くときに、彼らが何を期待しているかがわかるので、コードがより合理的になるでしょう。
あなたの言っていることから、彼らはphp開発者に対して偏見を持っている可能性があるように思えます。
コードレビュー自体については、すでにお伝えしたように、このような大量の小さなコメントは、いくつかの優れた有効な批判よりも役に立たないと考えています。また、コードレビューに関しては限られた経験しかありませんが、次のテクニックは、過去に私が働いたチームにとってはうまくいきました。
- まず、コードレビューが行われる前に、静的コードアナライザーを使用してほとんどの問題を特定する必要があります。例：Sonar、Lint、またはその他の優れたコードアナライザーを介してコードを実行すると、ほとんどの小さな問題を取り除くのに役立ちます。特に、レビュー担当者はカスタムプロファイルを定義して、ブラケットの配置、空白、コメント、適切な変数の命名など、すべてを保証できるため...
- 2つ目は、コメントをさまざまなカテゴリに分割するとうまくいくようです。たとえば、1つのグループに小さなものが含まれる2つのカテゴリには、注意して将来適用する必要があります。そして、別のコミットとその後のレビューを必要とするコードの即時変更を必要とするコメントの2番目のグループ。もちろん、後者のグループのコメントの数は少なくする必要があります。
さらに、最初の実際のコードレビューにも、当初の予想よりも多くのコメントが含まれていたと言わざるを得ません。しかし、これは悪いことだとは思っていませんでした。彼らのコメント²から学び続け、それらの新しく学んだテクニック/ベストプラクティスを将来のコード提出に適用したいのであれば、コメントは少なくなるはずです。確かに私にはそうだった;-)
¹私の経験では、これは多くのプログラマーがphpが最も邪悪なプログラミング言語であり、最も経験の浅いプログラマーがそれを使用していると主張しているためによく起こります。素晴らしいソフトウェアは任意の言語！
²コメントは過剰ですが、一部の値がその中にあると想定しています
誰もが日常的にコードレビューで100件以上のコメントを受け取ることは一般的ですか？私はそうは言いません。コードの品質が「望まれていることがたくさんある」人々にとって、絶対にたくさんのコメントを得ることは一般的ですか？.
ただし、コードレビュープロセスの「ルール」にも依存します。すべての人が何かをすべきだった方法について独自のアイデアを持っています。コードレビュープロセスで、コメントを「この方法ではなく、この方法で行う必要があります」という形式にすることが許可されている場合、適切なコードであっても、大量のコメントが表示される可能性があります。プロセスが「欠陥」を見つけることを目的としている場合、コメントの数ははるかに少なくする必要があります。
私の経験では、代替方法の「提案」を可能にするレビューは時間の浪費です。これらの「提案」は、レビュープロセスの外で1つずつ処理する必要があります。欠陥レビューは、「なぜ私がしたようにそれをしなかったのか」ではなく、人々がバグに集中できるようになるため、より有用です。また、誰かがバグを見つけても否定できないので、より便利です。したがって、傷ついた感情はありませんが、代わりに感謝の気持ちがありそうです。
更新：以上のことから、欠陥がなくても、一部のコードは明らかに悪いです。その場合、レビューコメントは何かのような単一のコメントにする必要があります。 「このコードはクリーンアップする必要があります。コードが[ここにあなたの名前]と話し合うまで、レビューを延期してください。」その場合、コメントが修正されるまで、コードのさらなるレビューは停止する必要があります。
UPDATE2：@User：開発中にコード/デザインについて話し合っていますか？あなたは彼らの提案に基づいてコードを開発している方法について何か変更を加えていますか？彼らのコメントから何かを学びますか？
私がプロジェクトのソフトウェアリーダーである場合、すべての作業成果物を担当するのが私の仕事です。私が作業成果物を承認した場合、その成果物は受け入れ可能であると主張しています。高品質な製品を作ることで定評があります。したがって、私は期待を持っており、満足のいくものを受け入れません。同時に、私の好みの理由を教えて説明しようとしています。それらの好みは常に理想的であるとは限りません（特に他の人の目には）が、それらの好みのほとんどは経験に基づいています。通常、悪いものを繰り返すことを避けるための反応。したがって、プッシュバックに関係なく、私の承認を得るために必要な私の個人的な「ステッカー」がいくつかあります。
反対に、あなたの作品を承認するために必要な期待を学ぶ必要があります。あなたは反対することもできますが、あなたが却下する権限を持っているようには見えないので、何が期待されているかを学んでください。チームがあなたを失敗させようとしているのではないかと思います。それも彼らが悪く見えるので。その点については、あなたが学びたくてないことを熱望していることを示し（そうでない場合でも）、彼らの発言を取り入れ、彼らの好みに適応するために最善を尽くすと、彼らはかなり遅れて見えるでしょう。たぶん、あなたが少なくとも耐えられるものを見つけ、彼らがあなたに彼らのやり方を教えるために彼らが少し手を握るかどうかを見てください。誰が知っているか、その過程であなたは本当にあなたのスキルを次のレベルに引き上げることができる何かを学ぶかもしれません。
私たちのチームの検査プロセスとのいくつかの重要な違い：
- 検査の基礎は、チーム全体によって編集されたチェックリストです。
- 焦点は欠陥（現在と未来）であり、スタイルのためのスタイルではありません。
- 3人の検査官（作成者を含む）が一緒に座ってコメントを実行します。過半数投票のコメントのみが残ります。
LOCが50の場合、300のコメントは少し過剰に見えるようです。あなたの会社には多くのリソースが必要です。
有用なコードレビュープロセスの私の経験から、いくつかのルールやガイドラインが必要です。
- コメントの優先度
- コメントの分類（バグ、コードスタイルなど）
- 同意するアーキテクチャ/設計に従う
- 合意されたコードスタイル
レビュー担当者から優先順位を取得できない場合は、担当のプロジェクトマネージャーまたはチームリーダーに依頼してください。費用の責任者は優先順位について意見を持つべきです。
定義されたアーキテクチャ、プロジェクトで使用する設計パターンの共通理解、および合意されたコードスタイルがある場合、レビューコメントは、セキュリティの問題、意図しないバグ、指定の対象外のコーナーケースなどの「実際の問題」のみに関するものでなければなりません。建築など.
開発チームが「味の問題」に同意していない場合（たとえば、メンバー変数が「m_」で始まる場合）、すべてのレビュアーは彼のスタイルに従うことを強制しますが、これは時間/お金の浪費です。
これは本当にコミュニケーションの問題のように聞こえます。あなたはあなたのコードが300のコメントに値するほど悪くないことを期待しています。レビュー担当者は、多くのフィードバックが必要だと考えているようです。非同期で前後に議論することは多くの時間を浪費することになります。 300のコメントを書くことは、時間の途方もない無駄です。これらがすべての欠陥ではない場合、チームのスタイルをまだ知らない可能性があります。これは正常なことであり、チーム全体を加速するために学ぶべきことです。
私の提案は時間を節約することです。フィードバックを加速します。私は...するだろう：
- 同じミスを犯したり、同じコメントを50回生成したりするのを避けるために、中間レビューをさらに行います。
- コードをレビューするときにレビュアーと一緒に座って、問題が発生したときに話し合うことができるようにします。これにより、次のコミットで消去される300の「問題」を文書化することを回避できます。
- コードを書いて、これらの「実際の」開発者の1人としばらくの間ペアを組んで、彼らがどのように異なるかを確認します。
「時間がかかる」のでペアリングに反対する人もいるだろうが、それは明らかにここでは問題ではない。