コードレビューでポジティブなものを見つける方法は？
昨年のいくつかの深刻な品質問題の後、私の会社は最近コードレビューを導入しました。コードレビュープロセスは、ガイドラインやあらゆる種類のチェックリストなしで、すぐに導入されました。
別の開発者と私は、トランクにマージされる前に、システムに加えられたすべての変更を確認することにしました。
「テクニカルリード」にも選ばれました。つまり、私たちはコードの品質に責任がありますが、プロセスに変更を実装したり、開発者を割り当て直したり、プロジェクトを保留したりする権限はありません。
技術的には、マージを拒否して、開発に戻すことができます。実際には、これはほぼ常に、予定通りに出荷することを上司に要求することで終わります。
私たちのマネージャーはMBAで、主に次のプロジェクトのスケジュールを作成することに関心があります。彼がしようとしている間、彼は私たちのソフトウェアがビジネスの観点から何をするのかほとんどわからず、開発者の説明なしに最も基本的な顧客の要求さえ理解するのに苦労しています。
現在、開発はSVNの開発ブランチで行われています。開発者は準備が整ったと考えた後、チケットシステムのチケットをマネージャーに再割り当てします。その後、マネージャーはそれを私たちに割り当てます。
コードレビューにより、チーム内にいくつかの緊張が生じています。特に一部の年配のメンバーは変更に疑問を呈しています（つまり、「私たちは常にこのようにしていた」または「メソッドに意味のある名前を付ける必要があるのに、私はそれが何をしているのか知っていますか？」）。
最初の数週間後、同僚は問題を起こさないようにして、同僚に問題を起こさないようにしました（顧客からバグレポートが提出された後、彼女はバグを知っていたが、開発者はそれを指摘することで彼女に腹を立てるでしょう。
一方、私は、コミットされたコードの問題を指摘するための尻として知られています。
私の基準は高すぎるとは思わない。
現時点での私のチェックリストは：
- コードがコンパイルされます。
- コードが機能する方法は少なくとも1つあります。
- コードはほとんどの通常のケースで動作します。
- コードはほとんどのEdgeケースで動作します。
- 挿入されたデータが有効でない場合、コードは適切な例外をスローします。
しかし、私はフィードバックを与える方法の責任を完全に受け入れます。私はすでに何かを変更する必要がある理由を説明する実用的なポイントを与えています。時には、何かが特定の方法で実装された理由を尋ねることさえあります。それが悪いと思うときは、別の方法で開発したと思います。
私が不足しているのは、「良い」と指摘するものを見つける能力です。悪い知らせを良い知らせに挟み込もうとするべきだと私は読んだ。
しかし、私は良いものを見つけるのに苦労しています。 「ねえ、今回は実際にやったことをすべてコミットした」というのは、ニースよりも軽蔑的で、役に立っています。
コードレビューの例
ジョー、
Library\ACME\ExtractOrderMailクラスでの変更についていくつか質問があります。
"TempFilesToDelete"を静的としてマークした理由がわかりませんでしたか？現時点では、 "GetMails"への2回目の呼び出しで例外がスローされます。これは、ファイルを追加した後、削除した後は削除しないためです。関数は実行ごとに1回だけ呼び出されることを知っていますが、将来的には変更される可能性があります。それをインスタンス変数にするだけで、複数のオブジェクトを並列にすることができます。
...（機能しない他のいくつかのポイント）
マイナーポイント：
- "GetErrorMailBody"がパラメータとして例外を受け取るのはなぜですか？私は何か見落としてますか？あなたは例外を投げているのではなく、それを渡して "ToString"を呼び出すだけです。何故ですか？
- SaveAndSendは、メソッドの適切な名前ではありません。このメソッドは、メールの処理が失敗した場合にエラーメールを送信します。 「SendErrorMail」などに名前を変更できますか？
- 古いコードをコメントするだけでなく、完全に削除してください。 Subversionにはまだ残っています。
コードレビューで肯定的なことを見つける方法は？
昨年のいくつかの深刻な品質問題の後、私の会社は最近コードレビューを導入しました。
すばらしい、あなたはあなたの会社に価値を生み出す真の機会を持っています。
最初の数週間後、私の同僚は、同僚に問題を起こさないように物事を滑らせ始めました（顧客からバグレポートが提出された後、彼女はバグを知っていたが、開発者がそれを指摘することで彼女に腹を立てるでしょう）。
同僚がコードの問題点を開発者に伝えることができない場合は、同僚がコードレビューを行うべきではありません。 問題を見つけて修正するのはあなたの仕事です前に顧客に影響を与えます。
同様に、同僚を威嚇する開発者が解雇を求めています。コードレビューの後に私は威圧されたと感じました-私は上司に話しました、そしてそれは処理されました。また、自分の仕事が好きなので、ポジティブとネガティブのフィードバックを続けました。レビュアーとして、それは私にあり、他の誰にもありません。
一方、私は、コミットされたコードの問題を指摘するための尻として知られています。
まあ、それは残念です、あなたはあなたが機知に富んでいると言います。あなたが探すものがもっとあれば、賞賛すべきものがもっとたくさんあります。
作者ではなくコードを批評する
あなたは例を挙げます：
の変更についていくつか質問があります
「あなた」と「あなたの」という言葉は避け、代わりに「the」の変更を言いましょう。
私は何か見落としてますか？ [...] 何故ですか？
あなたの批評に修辞的な繁栄を加えないでください。ジョークもしないでください。私が聞いたルールがあります、「それがあなたが言うのが良い気分になるなら、それを言わないでください、それは良くありません。」
たぶん、あなたは自分のエゴを誰かの犠牲でバフしているのかもしれません。事実だけにとどめてください。
肯定的なフィードバックを提供することで基準を引き上げる
開発者がより高い基準を満たすと、仲間の開発者を賞賛する基準が引き上げられます。つまり、質問、
コードレビューで肯定的なことを見つける方法は？
良いものであり、取り組む価値があります。
より高いレベルのコーディングプラクティスの理想にコードが適合する場所を指摘できます。
彼らがベストプラクティスに従い、水準を上げ続けるようにしてください。より簡単な理想が誰にでも期待できるようになった後、これらを称賛するのをやめて、称賛のためのさらに良いコーディングプラクティスを探す必要があります。
言語固有のベストプラクティス
言語がコード、名前空間、オブジェクト指向または関数型プログラミング機能のドキュメントをサポートしている場合は、それらを呼び出して、適切な場所でそれらを使用することを作成者に祝福できます。これらの問題は通常、スタイルガイドに該当します。
- 社内の言語スタイルガイドの基準を満たしていますか？
- その言語の最も信頼できるスタイルガイドに適合していますか（おそらく社内よりも厳格であり、社内スタイルに準拠しています）。
一般的なベストプラクティス
さまざまなパラダイムの下で、一般的なコーディングの原則を称賛するポイントを見つけることができます。たとえば、彼らには優れた単体テストがありますか？ユニットテストはほとんどのコードをカバーしていますか？
探す：
- 対象の機能のみをテストする単体テスト-テストすることを意図していない高価な機能を模倣します。
- 高レベルのコードカバレッジ、APIの完全なテスト、および意味論的にパブリックな機能。
- 単体テスト用にモックされた機能を含む、エンドツーエンドの機能をテストする受け入れテストとスモークテスト。
- 適切な名前、正規データポイントなので、コードはDRY（Do n't Repeat Yourself））で、マジックストリングや数字はありません。
- 変数の命名が非常にうまく行われているため、コメントはほとんど冗長です。
- クリーンアップ、客観的な改善（トレードオフなし）、適切なリファクタリングにより、コードを完全に元のライターと無関係にすることなく、コード行と技術的負債を削減します。
関数型プログラミング
言語が関数型である場合、または関数型パラダイムをサポートしている場合は、次の理想を探します。
- グローバルとグローバル状態を回避する
- クロージャーと部分関数の使用
- 読みやすく、正確で、わかりやすい名前の小さな関数
- 単一の出口点、引数の数を最小化
オブジェクト指向プログラミング（OOP）
言語がOOPをサポートしている場合、これらの機能の適切な使用法を称賛できます。
- カプセル化-明確に定義された小さなパブリックインターフェイスを提供し、詳細を隠します。
- 継承-おそらくミックスインを通じて、コードが適切に再利用されます。
- ポリモーフィズム-インターフェースが定義され、おそらく抽象基本クラス、パラメトリックポリモーフィズムをサポートするために記述された関数。
oOPの下には [〜＃〜] solid [〜＃〜] の原則もあります（OOP機能にいくつかの冗長性があるかもしれません）：
- 単一の責任-各オブジェクトには1つの利害関係者/所有者がいます
- オープン/クローズ-確立されたオブジェクトのインターフェースを変更しない
- Liskov置換-サブクラスを親のインスタンスの代わりに使用できます
- インターフェースの分離-構成、おそらくミックスインによって提供されるインターフェース
- 依存関係の逆転-定義されたインターフェース-ポリモーフィズム...
Unixプログラミング 原則 ：
Unixの原則は、モジュール性、明快さ、構成、分離、単純性、節約、透明性、堅牢性、表現、最小の驚き、沈黙、修復、経済性、生成、最適化、多様性、および拡張性です。
一般に、これらの原則は多くのパラダイムの下で適用できます。
あなたの基準
これらはあまりにも些細なことです-これを称賛されれば私は屈辱を感じるでしょう：
- コードがコンパイルされます。
- コードが機能する方法は少なくとも1つあります。
- コードはほとんどの通常のケースで動作します。
一方、あなたが何を扱っているかを考えると、これらはかなり高い評価であり、これを行うために開発者を賞賛することをためらわないでしょう：
- コードはほとんどのEdgeケースで動作します。
- 挿入されたデータが有効でない場合、コードは適切な例外をスローします。
コードレビューに合格するためのルールを書き留めますか？
それは理論的には素晴らしいアイデアですが、私は通常、不適切なネーミングのコードを拒否しませんが、ネーミングが非常に悪いので、修正するための指示とともにコードを拒否します。何らかの理由でコードを拒否できる必要があります。
コードを拒否するために私が考えることができる唯一のルールは、私がそれを本番環境に置かないようにするほど深刻なものは何もないということです。本当に悪い名前は、私が本番環境から遠ざけようとするものです-しかし、あなたはそれをルールにすることはできません。
結論
言語がそれらをサポートしている場合、複数のパラダイムの下で、おそらくすべてのパラダイムの下で従われているベストプラクティスを称賛することができます。
明確で簡潔な例であり、焦点を絞った問題に直接関連するものでない限り、何か良いものを選ぶのは面倒です。
私はそれをシュガーコートするつもりはありません-その音から、あなたは彼らの能力に不安があり、彼らの仕事について未熟な方法で挑戦されている少なくとも一人を扱っています。彼らはまた、彼らの仕事に悪い可能性があります-優れた開発者は、常に自己反省し、建設的な批判を受け入れ、彼らの方法を変えることを受け入れる必要があります。
さて、それは空中になっているので、あなたについて話しましょう。あなたが合理的であると思うかどうかに関係なく、あなたはボールを転がすためにこのような人々と特に注意する必要がある。私はこれらの人々に対処する最善の方法は、あなたが言葉で言う方法に非常に注意することです。
作成者ではなくコードを非難していることを確認してください。コードベースであるプーマウンテンではなく、手元にある1つの問題に焦点を当てます。コードベースは、作成に大きな影響を及ぼし、さらなる個人攻撃と見なされる可能性があります。最初に戦闘を選択し、ユーザーに顕在化する重要な問題に焦点を当てて、発言していることすべてを却下するように彼らを導く人に批判の連発を起こさないようにします。
直接話しかける場合は、ボディランゲージと口調が重要です。話していることを明確にし、相手に話しかけたり、技術的な能力を否定したりしないようにしてください。彼らはほとんどの場合、すぐに守備側にいるので、確認する代わりに心配を解決する必要があります。あなたは無意識のうちにあなたが彼らの側にいると思うように、あまりにも明白ではなく、この会話について意識する必要があります。うまくいけば、彼らは注意が向けられた変更を加える必要があることを受け入れます。
これがうまくいかない場合は、もう少し積極的に始めることができます。製品が会議室から実行可能な場合は、コードレビュー中にプロジェクターに持ち込み、バグを直接見せてください。マネージャーがそこにいて、人が後退できないようにするとよいでしょう。これは恥ずべきことではなく、問題がユーザーにとって現実のものであり、コードに不満を抱くだけでなく、修正する必要があることを受け入れるように強制するためです。
最終的にどこにも行かない場合、その人を幼稚園の生徒のように扱うのにうんざりしていて、管理者は問題を完全に認識しておらず、コードレビュー担当者としてのパフォーマンスにあまり反映されていないか、会社や製品の場合、上司に彼らの行動について話し始める必要があります。できるだけ具体的で人間味を欠く-生産性と品質が低下しているビジネスケースを作成します。
コードレビューは有毒で、時間を浪費し、オタク戦争を犠牲にする可能性があります。クリーンなコードとコメント、命名規則、単体テストと統合テスト、チェックイン戦略、RESTfulnessなどのようなものについての意見の相違を見てください。
これを確実に回避する唯一の方法は、コードレビューをパスするためのルールを書き留めることです
そうすれば、チェックインに失敗したり承認したりするのではありません。彼らは単にルールが守られていることを確認しているだけです。
そして、それらは事前に書き留められているので、コードを書くときにルールに従うことができ、理由を説明したり、後で引数をとったりする必要はありません。
ルールが気に入らない場合は、会議を開いてルールを変更してください。
フィードバックはひいきと見なされる可能性があるため、フィードバックはお控えください。
私の意見では、ベストプラクティスは常にコードに集中し、作成者に集中しないことです。
codeレビューであり、-developerレビューではないため、次のようになります。
- 「このwhileループは決して終わらないかもしれません」ではなく、「あなたのループは終わらないかもしれません」
- 「シナリオXにはテストケースが必要です」ではなく、「このシナリオをカバーするテストを記述していません」
レビューについて他の人と話しているときに同じルールを適用することも非常に重要です。
- 「アン、このコードについてどう思いますか？」ではなく、「アン、ジョンのコードについてどう思いますか？」
コードレビューは、パフォーマンスレビューの時間ではありません。個別に行う必要があります。
これまでのところどの回答にも記載されていないことに驚いています。おそらく、 my コードレビューの経験は珍しいものですが、
なぜマージ要求全体を1つのメッセージで確認するのですか？
コードレビューの私の経験はGitLabを介してです。他のコードレビューツールも同様に機能すると想像していました。
コードレビューを行うとき、特定の個々の行の差分についてコメントします。これは extremely であり、コードに関するコメントであるため、個人的な批判として受け取られる可能性は低く、実際には displayed としてコメントコード上、コードのすぐ下に表示され、コメントの対象となります。
マージ要求全体について also コメントできます。ただし、特定のポイントは、diffの特定の行で指摘できます。 （また、差分が変更されるように新しいコミットが追加されると、「古い差分」のコメントはデフォルトで非表示になります。）
このワークフローにより、コードレビューはよりモジュール化され、まとまりが少なくなります。コードレビューの行は、単に言うことができます、
専用の関数でこれをラップする素敵なアプローチ！
またはそれは言うかもしれません、
このオブジェクト名は、オブジェクトの目的と実際には一致しません。代わりに「XYZ」のような名前を使用できますか？
または、セクションに大きな問題がある場合は、次のように記述します。
このコードは機能します（そしてなぜ機能するかはわかります）と思いますが、理解するには集中的な研究が必要です。それを個別の関数にリファクタリングして、将来の保守が容易になるようにしていただけませんか？
（例：関数ABCは実際にここで3つのことを実行しています：fooのバズ、bozの禁止、およびzorfのフリッピング。これらはすべて個別の関数である可能性があります。）
上記のすべてを書き込んだ後、次のようなマージ要求全体に要約コメントを付けることができます。
これはすばらしい新機能であり、統合すると非常に役立ちます。関数の名前をクリーンアップして、私が行った個々のコメントに記載されているリファクタリングを処理してから、もう一度確認するように教えてもらえますか？ :)
マージ要求が完全な犬の朝食である場合でも個々のコメントはそれぞれ単純にすることができます。それらの数が増えるだけです。次に、要約コメントは次のようになります。
申し訳ありませんが、このコードは実際には十分ではありません。 Edgeのケースは非常に多くあり（個別のコメントに詳細が記載されています）、正しく処理されず、ユーザーエクスペリエンスが低下したり、1つのケースでデータが破損したりする可能性があります。 （commit 438a95fb734に関するコメントを参照してください。）いくつかの通常の使用例でも、アプリケーションのパフォーマンスが非常に悪くなります（詳細は、somefile.cのdiffに関する個々のコメントに記載されています）。
本番環境に対応するには、この機能を完全に書き直す必要があり、フローのすべてのポイントでどの仮定が安全であるかについてさらに注意を払う必要があります。 （ヒント：チェックされていない限り、安全な仮定はありません。）
完全な書き換えが完了するまでマージ要求を閉じます。
概要：コードの technical の側面をコードの個々の行のコメントとして確認します。次に、 summarize それらのコメントをマージリクエストに関する全体的なコメントに含めます。個人的なことはしないでください。事実について、そしてあなたの意見では、コードについて/であり、コーダーについてではありません。そして、事実、正確な観察、理解に基づいて意見を述べてください。
誰もそれを拾っていないことに本当に驚いていますが、投稿されたサンプルレビューに問題があります。
Joeに直接連絡する理由はありません。ジョーが彼の失敗を修正することはあなたのビジネスのどれでもありません。 誰かがすることはあなたのビジネスです。あなたの懸念はコードの品質です。ですから、リクエスト/注文/要求を書く代わりに（私がジョーだったとしても、あなたがこれに合法ではないので単に拒否することができます）、あなたの役割にとどまり、単純な匿名のToDoリストを書いてください。
良い点と悪い点を公平に示すことは不可能であるだけでなく、あなたの役割から完全に外れます。
あなたのレビューから抜粋した内容での再構成の例を以下に示します。
- Library\ACME\ExtractOrderMailクラスの変更をプルする前に、いくつかの問題を修正する必要があります。
- 私が何かを見逃していない限り、「TempFilesToDelete」は静的であってはなりません。
- 将来的には、実行ごとにこの関数を複数回呼び出す可能性があります。これが必要な理由です（ここで何をする必要があるか）。
- 「GetErrorMailBody」がパラメータとして例外を取得する理由を理解する必要があります。 （そして、私はここで境界線にいます、あなたはすでに結論を持っているはずだからです）
- SaveAndSendは、たとえば "SendErrorMail"のように、その動作に合わせて名前を変更する必要があります。
- コメント化されたコードは、読みやすくするために削除する必要があります。最終的なロールバックにはSubversionを使用します。
このようにレビューを作成すると、読者が個人的にどれほど嫌いであっても、ここで確認できるのは、後で誰かが実行しなければならない改善に関するメモだけです。 WHO ？いつ ？誰も気にしない。何 ？どうして ？あなたが言うべきこと。
ここで、コードレビューが緊張が高まっているまさにその理由に対処するために、人的要因を方程式から除外します。
コードレビューの全体のポイントは、問題を見つけることです。 anyバグがある場合、最善の方法は、失敗するテストケースを記述することです。
チーム（マネージャー）は、バグの生成はゲームの一部であることを伝える必要がありますが、バグを見つけて修正することでeverybody'sジョブを節約できます。
定期的な会議（チームまたはペアのいずれか）を行い、いくつかの問題を解決することが役立つ場合があります。元のプログラマーは意図的に問題を導入していませんでした。また、それで十分だと思う場合もあります（場合によっては問題ないこともあります）。しかし、その2つ目の目を持つことで完全に新鮮な見方が得られ、問題を調べることで彼は大いに学ぶことができます。
それは本当に文化的なものであり、多くの信頼とコミュニケーションが必要です。そして、結果を処理する時間です。
レビューを行う前に、コーディング標準についてコンセンサスを得ることは良いことだと思います。他の人々は、彼らがインプットを持っているとき、何かをより多く買う傾向があります。
命名規則などについては、これが重要かどうかを他の人に尋ねてください。ほとんどの開発者は、特に仲間の間で同意します。プログラミングの世界で流行していることに同意したくない人になりたいのは誰ですか？誰かのコードを選んで欠陥を指摘することでプロセスを開始すると、彼らは非常に防御的になります。基準が確立されると、解釈や「十分に良い」と見なされるものに不一致が生じますが、あなたは今よりも裕福です。
このプロセスのもう1つの部分は、コードレビューで異論を処理する方法を決定することです。これは無限の議論になることはできません。ある時点で、誰かが決定を下さなければなりません。たぶん、裁判官になる第三者がいるかもしれませんし、査読者がすべての力を手に入れているかもしれません。物事を成し遂げる必要があることを目標にする必要があります。
この最後の部分は、コードレビューがあなたのアイデアではなかったことを皆に知らせることです。彼らはとどまるので、誰もがそれを最大限に活用するために努力する必要があります。誰もが無力だと感じた場合、おそらく彼らはあなたのコードをレビューすることを許可されますか？
うまくいけば、管理の測定可能な結果は、バグ、顧客の苦情、遅延などを制限することです。それ以外の場合、誰かが流行語の「コードレビュー」を聞いて、それをプロセスに追加しただけだと考えた場合、奇跡は多くの時間とエネルギーなしで発生しますこれに力を入れました。
これは厳しいかもしれませんが、測定するものがない場合でも良いフィードバックを与えることを心配しないでください。
ただし、将来的には、開発者がコードを改善し始めるときに、適切なフィードバックを提供する必要があります。コードの改善点と、チーム全体のメリットを指摘する必要があります。改善が見られるようになると、改善も見られ、物事はゆっくりと起こり始めます。
別物;彼らは発言権がないかのように感じるので、防御的な空気があるかもしれません。彼らにお互いのコードをレビューさせてみませんか？彼らに具体的な質問をして、彼らを巻き込むようにしてください。それはあなた対彼らではありません。それはチームの努力であるべきです。
- 時間があれば、このコードについて何を変更しますか？
- コードベースのこの領域をどのように改善しますか？
今それを尋ねなさい、そして今から半年も尋ねなさい。ここには学習体験があります。
重要な点-正当化されないコードに関して賞賛を与えないでください。努力を認め、改善を明確に認めてください。レビューを敵対的なものではなく、チームで行うようにしてください。
緊張のない品質
どのようにしてコードについて肯定的なことを言うかを尋ねましたが、実際の問題は、「深刻な品質の問題」に対処しながら「[チーム]内の緊張」を回避する方法です。
「悪い知らせを良い知らせに」という古いトリックは裏目に出るかもしれません。開発者は、それが何であるかについて、それを見る可能性があります：仕掛け。
組織のトップダウンの問題
あなたの上司はあなたに品質を保証するように命じました。コード品質の基準のリストが思い付きました。今、あなたはあなたのチームに提供する前向きな強化のためのアイデアを求めています。
チームを幸せにするために何が必要なのか、なぜ私たちに尋ねるのですか？ チームに質問することを検討しましたか？
ニースになるために最善を尽くしているようです。問題は、メッセージの配信方法ではありません。問題は、コミュニケーションが一方通行であったことです。
品質の文化を築く
品質の文化は、ボトムアップで成長するために育まれなければなりません。
品質が十分に向上していないことを懸念している上司に知らせてください ハーバードビジネスレビュー からのアドバイスを適用してみてください。
あなたのチームと会います。チームで見たい行動をモデル化します。謙遜、敬意、そして改善への取り組みです。
次のように言います：「ご存知のように、[同僚]と私には、最近発生した本番環境の問題を防ぐために、コードの品質を確保する役割がありました。私は個人的にこの問題を解決したとは思いません。私の最大の間違いは、最初はあなた方全員を巻き込むことではなかったと思います。 [同僚]と私はまだコード品質の管理に責任を負っていますが、今後は全員で品質向上に取り組んでいます。 "
コードの品質についてチームからアイデアを得る。 （ホワイトボードが役立ちます。）要件が最後までそこに入るようにしてください。適切な方法で洞察を提供し、必要に応じて質問します。チームが重要だと感じていることに驚いても構わない。ビジネスニーズを損なうことなく、柔軟に対応します。
（恥ずかしい古いコードがある場合、それをだまして、みんなが率直になるように奨励するかもしれません。最後に、人々にそれを書いたことを知らせてください。他の人が建設批判を受けたときに期待する成熟した反応をモデル化してください。 ）
共同コードレビュー
私は、あなたが説明しているような場所で働いたことはありません。そこでは、何人かの上級プログラマーがすべてのコードをレビューして修正します。教師が紙に赤いマークを付けるように反応するのも不思議ではありません。
アイデアを管理に売り込むことができるなら、 ピアコードレビュー を始めてください。これは、あなたや他の責任ある開発者を含む小さなグループで行うのが最善です。全員が敬意を持って扱われるようにします。
ピアレビューコードの重要な目標は、チームのすべてのメンバーがコードを理解できるようにすることです。関数名が不明確な例を考えてみましょう。上級開発者からの別の「修正」よりも、関数名がわかりにくいとジュニア開発者から聞いた方が受け入れやすい場合があります。
品質は旅です
もう1つ行うべきことは、コードレビューが合格/不合格のようなものであるという概念を一掃することです。誰もがコードレビュー後にいくつかの編集を行うことを期待する必要があります。 （そしてあなたの仕事はそれらが確実に起こるようにすることです。）
それでもうまくいかない場合は...
品質の文化を確立するために、いくつかの進歩を遂げたとしましょう。それでも、全員が参加するわけではありません。誰かがまだ品質プログラムに参加していない場合、問題は、2人の間に問題があるのではなく、チームに適合していないことです。彼らがチームから解任される必要がある場合、チームの他のメンバーは理由をよりよく理解するでしょう。
もう1つの長い回答で申し訳ありませんが、他の人がこの問題の人間的な要素に完全に対処しているとは思いません。
時々、何かが特定の方法で実装された理由を尋ねることさえあります。それが悪いと思うときは、別の方法で開発したと思います。
「なぜこのように実装したのですか？」の問題開発者をすぐに守備に置くことです。質問自体は、状況に応じてあらゆる種類のことを暗示する可能性があります。あなたはより良い解決策を考えるのが愚かですか？これはあなたができる最高のことですか？このプロジェクトを台無しにしようとしていますか？あなたもあなたの仕事の質を気にしていますか？などなぜコードが特定の方法で開発されたのかを問うことは対立するだけであり、それはあなたのコメントが持っていたかもしれない教育的意図を覆すことになります。
同様に、「私はこれを別様にやっただろう...」も対立します。なぜなら、開発者がすぐに考えているのは「まあ、私はこのようにやったのです... 問題が発生しましたか？ "繰り返しになりますが、必要以上に対立的であり、議論をコードの改善から遠ざけます。
例：
「なぜこの値に定数変数を使用しないことを選んだのですか？」と尋ねる代わりに、単に「このハードコードされた値はファイル_Constants.h_内の定数XYZで置き換える必要があります」と述べます。質問は、開発者がすでに定義された定数を使用するために積極的に not を選択したことを示唆していますが、それが存在することさえ知らなかった可能性もあります。十分な大きさのコードベースがあると、各開発者が知らないことがたくさんあります。これは、単にその開発者がプロジェクトの定数について知るための良い学習機会です。
コードレビューには注意が必要です。言うことすべてをシュガーコートする必要はありません。悪いニュースを良いニュースでサンドイッチする必要はなく、打撃を和らげる必要はありません。それは私がいる文化かもしれませんが、私の同僚と私はコードレビューでお互いに褒めることはありません-私たちが開発したコードの欠陥のない部分は十分に賛辞です。あなたがする必要があるのは、あなたが見た欠陥を特定し、そしておそらく理由を与えることです（なぜそれが明白/単純である場合、その理由はあまり役に立ちません）。
良い：
「この変数の名前は、コーディング標準に合わせて変更する必要があります。」
「この関数名の「b」は、PascalCaseにするために大文字にする必要があります。」
「この関数のコードは適切にインデントされていません。」
「このコードは
ABC::XYZ()にあるコードの複製であり、代わりにその関数を使用する必要があります。」「 try-with-resources を使用する必要があります。これにより、エラーが発生した場合でも、この関数で正しくクローズされることが保証されます。」 [ここにリンクを追加しただけなので、Java以外のユーザーはtry-with-resourcesの意味を理解できます]
「この関数は、nパスの複雑さの基準を満たすためにリファクタリングする必要があります。」
悪い：
「私は think 変数名を変更して標準に一致させることで、このコードを改善できます」
"たぶん try-with-resourceを使用して、この関数内の物を適切に閉じる方が良いでしょう"
「この関数のすべての条件をもう一度見直すことが望ましいかもしれない。そのNパスの複雑さは、私たちの標準の最大許容複雑さを超えています。」
「なぜここのインデントは標準の4の代わりに2スペースなのですか？」
「なぜnパスの複雑さの標準を破る関数を書いたのですか？」
悪い説明では、斜体の部分は、打撃を和らげたいときに一般的に使用されるものですが、コードレビューで実際に行われているのは、自分を不確かにさせることだけです。レビュー担当者がコードを改善する方法がわからない場合、なぜ誰かがあなたの意見を聞く必要があるのでしょうか。
「良い」発言は率直ですが、彼らは開発者を非難したり、開発者を攻撃したりせず、対立するものではなく、欠陥が存在する理由を疑問視しません。それが存在します;ここに修正があります。彼らは確かに最後の「なぜ」の質問ほど対立的ではありません。
あなたが見る問題は次のとおりです：開発者は彼らのコードが批判されることを不満に思っています。しかし、それは問題ではありません。問題は、彼らのコードが良くないということです（あなたのコードレビューが明らかに良いと仮定すると）。
開発者が批評を引き付けるコードを好まない場合、解決策は簡単です。より優れたコードを記述します。あなたはコードの品質に深刻な問題があったと言います。つまり、より優れたコードが必要です。
「なぜメソッドにわかりやすい名前を付けるべきなのか、私はそれが何をするのか知っていますか？」私は特に気になるものです。彼はそれが何をするか知っているか、少なくとも彼はそう言っていますが、私は知りません。どのメソッドにも、わかりやすい名前を付けるだけでなく、コードの読者がその機能をすぐに理解できるような名前にする必要があります。 AppleのWebサイトにアクセスして、Swift 2からSwift 3への変更に関する膨大な数の変更が加えられました。おそらく、この種のビデオは、直感的なメソッド名が非常に重要であると考えるよりもはるかに賢い開発者に、開発者を納得させるかもしれません。
別の気がかりな項目は、「顧客からバグレポートが提出された後、彼女はバグを知っていたが、開発者がそれを指摘することに腹を立てるのではないかと彼女は私に言いました」と言った同僚でした。誤解がある可能性もありますが、開発者がバグを指摘して怒った場合は、それは悪いことです。
私はあなたが説明したコードレビューの方法に敬意を払いません。 2人のスタッフが「密室」に出て、批判を表明するinstitutionalizes優れたコードレビューは、非常に一種の敵対的な概念である回避。
コードレビューをできる限りポジティブなエクスペリエンスにすることは、コードレビューを成功させるために不可欠です。最初のステップは、逆説的なレビューの概念を取り除くことです。毎週または隔週groupイベントにしてください。参加を歓迎していることを誰もが知っていることを確認してください。ピザやサンドイッチなどで注文してください。それが否定的な意味合いを掻き立てるなら、それを「コードレビュー」とさえ呼ばないでください。祝い、励まし、共有する何かを見つけましょう。たとえそれが現在のスプリントやイテレーションの進歩にすぎない場合でもです。順番にレビューに対してリーダーシップを割り当てます。
プロセスを製品と人々に奉仕する努力をします。それらが建設的かつ積極的に行われる場合、良い技術やパターンが共有され、貧しい人々が落胆するのと同じように奨励されます-誰もが利益を得ます。誰もが公共の場で指導を受けます。 「理解できない」プログラマーに問題がある場合、それらは非公開で個別に対処する必要があります。より広いグループの前では決して対処しないでください。これはコードレビューとは別のものです。
持っていく「良い」ものを見つけるのに苦労している場合、それは私に疑問を投げかけます：プロジェクトで進歩があり、人々が働いているなら、その進歩自体は祝うべきものです。あなたが本当にnothingを見つけているのであれば、それは最後のレビュー以降に行われたすべてのことはbadまたはneutralより良くないことを意味します。それは本当ですか？
詳細は共通規格が必須です。何が行われているのかをみんなに知ってもらう。そして、より新しくより優れた手法をコードベースに統合できるようにします。古い習慣を保証することを怠ったことは、「私たちは常にそのようにしてきた」という偽装で決して排除されることはありません。
これらすべての要点は、コードレビューは実装が不十分で、経験の浅いプログラマや熟練度の低いプログラマのハンマーとして使用されているため、少し悪いラップが与えられており、誰も役に立たないということです。これらをこのように使用するマネージャーも、あまり効果的なマネージャーではない可能性があります。誰もが参加者である優れたコードレビューは、製品、従業員、会社など、すべての人にサービスを提供します。
投稿の長さについてお詫びしますが、コードレビューがほとんど無視されていたグループに所属していたため、保守不可能なコードのレガシーが発生し、数年前のコードベースに変更を加えることを許可されていても、限られた範囲の開発者しかできませんでした。それは私が二度と横断しないことを選んだ道でした。
優れたコードのパラドックスは、まったく目立たないことであり、非常に単純で簡単に記述できるように見えます。私は本当に この答え のプールプレーヤーの例が好きです。コードレビューでは、それがたまたま悪いコードからのリファクタリングである場合を除いて、それは本当に簡単に理解することができます。
私はそれを探すことにします。コードをレビューしていて、読みやすく、一見簡単に書けるように思えるファイルを調べた場合は、「ここのメソッドがどのように短くクリーンであるか」など、適切なものをすばやく投入します。 。
また、模範を示す必要があります。コードもレビューするように主張し、修正を受けたときのチームの動作をモデル化する必要があります。最も重要なのは、フィードバックに対して人々に心から感謝することです。これにより、一方的なフィードバックよりも大きな違いが生まれます。
本当の問題は、すべてのコードレビューを行っているのはたった2人であり、そのうち真剣に受け止めているのはあなただけであり、多くの責任と多くのことを伴う不幸な状況に陥ったことです他のチームメンバーからの圧力。
より良い方法は、コードレビューを行う責任をチーム全体に分散させ、たとえば、コードをレビューする人を開発者が選択できるようにするなど、全員に参加してもらうことです。これは、コードレビューツールがサポートする必要があるものです。
私はこれが直接発生するのを見てきましたが、 感情的知性 の挑戦的な答えに注意してください-彼らはチーム全体を殺すことができます。毎年、新しい開発者を採用、トレーニング、正規化したい場合を除いて、仲間との良好な関係を築くことが不可欠です。結局のところ、これらのレビューを実施してコードの品質を向上させ、そもそもコードの品質がより高い文化を育むことが重要ではないでしょうか。このコードレビューシステムをチームカルチャーに統合する手段として積極的な強化を提供することは、あなたの仕事の一部だと私は主張します。
とにかく、コードレビューシステムを確認する必要があるようです。現在、そのサウンドから、レビュープロセスのすべてが客観的というよりも主観的である、または主観的であると解釈できます。誰かがガイドラインに適合しない場合に引用できる理由があるのではなく、誰かがコードを好きではないためにコードを分解しているように感じた場合、傷ついた感情を感じるのは簡単です。このように、オフィスカルチャーに適した方法で、（レビューシステムに関して）追跡し、コード品質のポジティブな改善を「祝う」ことが容易になります。
テクニカルリードは、レビューセッションの外で集まり、コーディングガイドライン/コードレビューチェックリストを作成する必要があります。また、レビュー中に遵守し、参照する必要があります。これは、プロセスの進展に合わせて更新および改良できる、生きたドキュメントでなければなりません。これらの技術リーダー会議は、開発者がコードの結果の不一致のようにレビューされないでレビューされることなく、「常に私たちが物事を行った方法」対「物事の新しい改善された方法」の議論が行われるべきときでもあるはずです。最初のガイドラインが多少平滑化された後、開発者を積極的に強化する別の方法は、フィードバックを求めてから実際にアクションを実行することですチームとしてプロセスを進化させれば、オンボードのコードのレビューを開始できるようになるため、引退するまでレビューに行き詰まることはありません。
前提...
プログラマーは問題解決者です。問題またはエラーが発生した場合、デバッグを開始することが条件付けられています。
コードはアウトライン形式の媒体です。フィードバックをパラグラフ形式のナラティブに切り替えると、翻訳が必要な切断が生じます。必然的に何かが失われたり、誤解されたりします。避けられないことに、レビュアーはプログラマーの言語で話していません。
コンピュータで生成されたエラーメッセージはめったに質問されず、決して個人的な侮辱とは見なされません。
コードレビュー項目は、人間が生成したエラーメッセージです。これらは、プログラマーや自動化ツールが見逃すエッジケースや、他のプログラムやデータへの避けられない副作用を捉えることを目的としています。
結論...
したがって、より多くのコードレビュー項目を自動化ツールに組み込むことができるほど、それらはより良く受信されます。
注意すべき点は、疑いの余地がないように、そのようなツールは、手順、標準、および慣例のすべての変更に準拠するために、通常は毎日または毎週継続的に更新する必要があることです。マネージャーまたは開発者チームが変更を行うことを決定した場合、それを実施するためにツールを変更する必要があります。コードレビューアーの仕事の多くは、ツールのルールを維持することになります。
コードレビューのフィードバック例...
これらのテクニックを組み込んだ例の書き直し：
件名：
- Library\ACME\ExtractOrderMail Class。
原則の問題...
- TempFilesToDeleteは静的です
- GetMailsへの後続の呼び出しは、ファイルが追加されたために例外をスローしますが、削除後に削除されることはありません。現在は1つの呼び出しのみですが、ある程度の並列処理により、将来的にパフォーマンスが向上する可能性があります。
- TempFilesToDeleteをインスタンス変数として使用すると、複数のオブジェクトを並行して使用できます。
- 二次的な問題...
- GetErrorMailBodyには例外パラメーターがあります
- それ自体は例外をスローせず、これをToStringに渡すだけなので、必要ですか？
- SaveAndSendの名前
- 電子メールは将来これを報告するために使用される場合と使用されない場合があり、このコードには永続的なコピーを保存してエラーを報告するための一般的なロジックが含まれています。より一般的な名前は、依存するメソッドに変更を加えることなく、そのような予期される変更を可能にします。 1つの可能性はStoreAndReportです。
- 古いコードをコメント化
- コメントを付けてOBSOLETEとマークした行を残すとデバッグに非常に役立ちますが、「コメントの壁」によって隣接するコードのエラーがわかりにくくなる場合もあります。 Subversionにはまだ残っています。おそらく、Subversionの正確な場所を参照するコメントでしょうか？
既存のコード（理解しやすいように聞こえます）について何も言っていない場合は、開発者にコードの改善に参加してみてください。
機能変更またはバグ修正のためのパッチでは、同じパッチにバンドルされている他の変更（名前の変更、リファクタリングなど）は役に立ちません。バグを修正したり、機能を追加したりする変更のみを行う必要があります。
名前の変更、リファクタリング、およびその他の変更areが示されている場合は、それらを前または後の別のパッチで実行します。
これはかなり醜いですが、他のすべての厄介なコードと一致していると思います。後でそれをクリーンアップしましょう（理想的には機能の変更がないパッチで）。
また、リファクタリングに参加し、themレビューyourコードを使用する場合にも役立ちます。それはあなたが何かが悪いというよりはなぜ良いと思うのかを述べる機会を与え、また建設的な批評をうまくとる例を示す機会を与えます。
ユニットテストを新機能に追加する必要がある場合は、メインパッチに含めます。しかし、バグを修正している場合、テストは以前のパッチで実行する必要があります渡さないでください修正が実際にバグを修正したことを実証できます。
理想的には、計画（修正をテストする方法、または何をリファクタリングするか、いつ行うか）は、作業が完了する前に話し合う必要があります。そうすることで、問題があることを見つける前に、何かに多くの労力を費やさないようにします。
コードが適切と思われる入力に対応していない場合は、開発者が妥当な入力と見なしているものも一致していない可能性があります。可能であれば、事前に同意します。少なくとも、それが何に対処できるべきか、そしてそれがどれほど厄介に失敗することを許され得るかについていくつかの議論があります。
技術的または簡単な解決策があると想定するのは誤りだと思います。「自分の仕事を私の基準で判断すると、同僚は動揺し、それを強制する力がある」。
コードレビューは、何が良いか悪いかについての単なる議論ではないことを覚えておいてください。それらは暗黙のうちに「私たちが使用しているのは誰のヤードスティック」、「誰が決定を下すのか」であり、それゆえに-最も油断なく-ランクです。
これらの点に対処しないと、発生した問題が発生しない方法でコードレビューを行うことが困難になります。これを行う方法についていくつかの良いアドバイスがありますが、あなたはあなた自身を難しい仕事に設定しました。
もしあなたが正しいなら、小刻みな部屋なしで、それを指摘することは攻撃です：誰かがめちゃくちゃになりました。そうでない場合：それを取得しない別のMBA。いずれにせよ、あなたは悪者になるでしょう。
ただし、レビューの内容とwhyが明確で合意されている場合は、悪者ではない可能性があります。あなたはゲートキーパーではなく、単なる校正者です。この合意を得ることは解決するのが難しい問題です[1]。アドバイスしたいのですが、まだコツがわからないので...
[1]人々が「大丈夫」と言った、またはそれについての争いをやめたからといって、それは解決されません。 Xが{インテリジェンス、経験、人材、締め切りなど}にとって実用的ではない、と言う人は誰もいませんが、実際にXを実行する特定のインスタンスに関しては、それは意味がありません...