昨年の深刻な品質問題の後に、私の会社は最近コードレビューを導入しました。コードレビュープロセスは、ガイドラインやチェックリストなしですぐに導入されました。

別の開発者と私は、システムに加えられたすべての変更を、トランクにマージする前に確認することにしました。

また、「テクニカルリード」に選ばれました。つまり、コードの品質には責任がありますが、プロセスの変更を実装したり、開発者を再割り当てしたり、プロジェクトを保留したりする権限はありません。

技術的には、マージを拒否して、開発に戻すことができます。現実には、これはほとんどの場合、上司が期限内に出荷することを要求することで終わります。

私たちのマネージャーは、今後のプロジェクトのスケジュールを作成することに主に関心があるMBAです。彼が試みている間、彼は私たちのソフトウェアがビジネスの観点から何をするのかほとんどわからず、開発者からの説明なしに最も基本的な顧客の要求さえ理解しようと努力しています。

現在、開発はSVNの開発ブランチで行われています。開発者は準備ができたと判断した後、チケットシステムのチケットをマネージャーに再割り当てします。マネージャーはそれを私たちに割り当てます。

コードレビューにより、チーム内でいくつかの緊張が生じています。特に、古いメンバーの一部は、変更に疑問を呈しています（つまり、「常にこのようにしていた」または「メソッドに意味のある名前が必要なのはなぜか、わかりますか？」）。

最初の数週間後、同僚が問題を起こさないように、同僚が物事を滑らせ始めました（バグ報告が顧客によって提出された後、彼女はバグを知っていたが、開発者はそれを指摘することに彼女に腹を立てます）。

一方、私は現在、コミットされたコードの問題を指摘するためのお尻であることで知られています。

私の基準が高すぎるとは思わない。

現時点での私のチェックリストは次のとおりです。

• コードがコンパイルされます。
• コードが機能する方法は少なくとも1つあります。
• コードはほとんどの通常のケースで機能します。
• コードはほとんどのエッジケースで動作します。
• 挿入されたデータが有効でない場合、コードは妥当な例外をスローします。

しかし、私はフィードバックを行う方法の責任を完全に受け入れます。私はすでに、何かを変更する理由を説明するアクション可能なポイントを既に与えています。悪いと思うときは、別の方法で開発していたと指摘します。

私が欠けているのは、「良い」と指摘するものを見つける能力です。悪いニュースを良いニュースに挟もうとするべきだと読みました。

しかし、私は良いものを見つけるのに苦労しています。「今度は、実際にあなたがしたことをすべてコミットした」というのは、すてきで助けになるというよりも、お世辞です。

サンプルコードレビュー

こんにちはジョー、

Library \ ACME \ ExtractOrderMailクラスの変更について質問があります。

「TempFilesToDelete」を静的としてマークした理由がわかりませんでしたか？現時点では、「GetMails」への2回目の呼び出しは例外をスローします。これは、ファイルを追加したが、削除した後に削除しないためです。関数は実行ごとに1回だけ呼び出されることを知っていますが、将来的には変更される可能性があります。インスタンス変数にするだけで、複数のオブジェクトを並行して使用できます。

...（機能しない他のポイント）

マイナーポイント：

• 「GetErrorMailBody」がパラメーターとして例外を受け取るのはなぜですか？私は何か見落としてますか？例外をスローするのではなく、単に例外を渡して「ToString」を呼び出します。何故ですか？
• SaveAndSendはMethodの適切な名前ではありません。このメソッドは、メールの処理が失敗した場合にエラーメールを送信します。名前を「SendErrorMail」などに変更できますか？
• 古いコードをコメントするのではなく、完全に削除してください。まだ転覆中です。

コードレビューでポジティブなものを見つける方法は？

昨年の深刻な品質問題の後に、私の会社は最近コードレビューを導入しました。

素晴らしい、あなたはあなたの会社のために価値を創造する本当の機会を持っています。

最初の数週間後、同僚は物事を滑らせ始め、同僚とのトラブルを引き起こしませんでした（バグレポートが顧客によって提出された後、彼女はバグを知っていたが、開発者が彼女にそれを指摘することに怒っているでしょう）。

同僚は、開発者にコードの何が問題なのかを伝えることができない場合、コードのレビューを行うべきではありません。問題を見つけて顧客に影響を与える前に修正するのはあなたの仕事です。

同様に、同僚を威developerする開発者は解雇を求めています。コードレビューの後に脅迫されたと感じました。上司に話しましたが、それは処理されました。また、私は自分の仕事が好きなので、ポジティブとネガティブのフィードバックを続けました。レビュアーとして、それは私にあり、他の誰にもありません。

一方、私は現在、コミットされたコードの問題を指摘するためのお尻であることで知られています。

まあ、それは残念です、あなたはあなたが機知に富んでいると言います。探しているものがもっとあるなら、あなたは賞賛するものをもっと見つけることができます。

著者ではなくコードを批判する

あなたは例を挙げます：

あなたの変更についていくつか質問があります

代わりに「あなた」と「あなたの」という言葉の使用を避け、「その」と言います。

私は何か見落としてますか？[...] 何故ですか？

批評に修辞的な装飾を加えないでください。冗談も言わないでください。私が聞いたルールは、「もしあなたがそれを言って良い気分にさせたら、それを言わないでください、それは良くありません。」です。

たぶん、あなたは他の誰かの費用であなた自身の自我をバフしているでしょう。事実だけを守ってください。

正のフィードバックを提供して水準を引き上げる

仲間の開発者がより高い基準を満たしたときに、仲間の開発者を称賛するための基準を引き上げます。それは質問を意味します

コードレビューでポジティブなものを見つける方法は？

良いものであり、対処する価値があります。

コードがどこでより高いレベルのコーディング慣行の理想を満たしているかを指摘できます。

ベストプラクティスに従って、水準を上げ続けるために彼らを探してください。誰にとっても簡単な理想が期待されるようになったら、これらを賞賛するのをやめ、賞賛のためのより良いコーディングの実践を探したいと思うでしょう。

言語固有のベストプラクティス

言語がコード、名前空間、オブジェクト指向または関数型プログラミング機能のドキュメントをサポートしている場合、それらを呼び出して、必要に応じて使用することを作者に祝福できます。これらの問題は通常、スタイルガイドに該当します。

• 社内の言語スタイルガイドの基準を満たしていますか？
• 言語の最も権威のあるスタイルガイド（おそらく社内よりも厳密であるため、社内スタイルに準拠しています）に適合していますか？

一般的なベストプラクティス

さまざまなパラダイムの下で、一般的なコーディングの原則を称賛するポイントを見つけることができます。たとえば、優れた単体テストはありますか？ユニットテストはほとんどのコードをカバーしていますか？

探す：

• 対象の機能のみをテストする単体テスト-テスト対象ではない高価な機能をモックします。
• APIおよびセマンティックパブリック機能の完全なテストによる、高レベルのコードカバレッジ。
• 受け入れテストと、単体テスト用にモックされた機能を含むエンドツーエンドの機能をテストするスモークテスト。
• 適切な名前付け、正規のデータポイント。コードはDRY（Do n't Repeat Yourself）であり、魔法の文字列や数字はありません。
• 変数の命名が非常によくできているため、コメントはほとんど冗長です。
• クリーンアップ、客観的な改善（トレードオフなし）、適切なリファクタリングにより、コードを元のライターから完全に異質にすることなく、コード行と技術的負債を削減します。

関数型プログラミング

言語が機能している場合、または機能的なパラダイムをサポートしている場合は、次の理想を探してください。

• グローバルとグローバル状態の回避
• クロージャーと部分関数を使用する
• 読みやすく、正確で、わかりやすい名前の小さな関数
• 引数の数を最小化する単一の出口点

オブジェクト指向プログラミング（OOP）

言語がOOPをサポートしている場合、これらの機能の適切な使用法を賞賛できます。

• カプセル化-明確に定義された小さなパブリックインターフェイスを提供し、詳細を隠します。
• 継承-おそらくミックスインを通じて適切に再利用されたコード。
• ポリモーフィズム-インターフェイス、おそらく抽象ベースクラス、パラメータポリモーフィズムをサポートするために作成された関数が定義されます。

OOPの下では、SOLID原則もあります（OOP機能の冗長性があるかもしれません）：

• 単一の責任-各オブジェクトには1人の利害関係者/所有者がいます
• オープン/クローズ-確立されたオブジェクトのインターフェースを変更しない
• リスコフ置換-サブクラスで親のインスタンスを置換できます
• インターフェース分離-コンポジション、おそらくミックスインによって提供されるインターフェース
• 依存関係の逆転-定義されたインターフェイス-多態性...

Unixプログラミングの原則：

Unixの原則は、モジュール性、明快さ、構成、分離、単純さ、節約、透明性、堅牢性、表現、最小驚き、沈黙、修理、経済、生成、最適化、多様性、および拡張性です。

一般に、これらの原則は多くのパラダイムの下で適用できます。

あなたの基準

これらはあまりにも些細なことです-これを賞賛するなら、私は軽desするでしょう：

• コードがコンパイルされます。
• コードが機能する方法は少なくとも1つあります。
• コードはほとんどの通常のケースで機能します。

一方、これらはあなたが何に対処しているように見えるかを考えると、かなり高い評価です。

• コードはほとんどのエッジケースで動作します。
• 挿入されたデータが有効でない場合、コードは妥当な例外をスローします。

コードレビューを渡すためのルールを書き留めていますか？

これは理論上は素晴らしいアイデアですが、通常、不適切な名前付けのためにコードを拒否することはありませんが、修正するための指示でコードを拒否するほどひどい名前付けを見てきました。何らかの理由でコードを拒否できる必要があります。

コードを拒否するために私が考えることができる唯一の規則は、私がそれを生産から外しておくほどひどいものは何もないということです。本当に悪い名前は、私が本番環境を避けたいと思うものですが、それをルールにすることはできません。

結論

言語がそれらをサポートしている場合、複数のパラダイムの下で、そしておそらくそれらすべての下で守られているベストプラクティスを賞賛することができます。

しっかりとした簡潔な例で、焦点を絞った問題に直接関係しない限り、良いものを選ぶことを気にしないでください。

私はそれをシュガーコートしません-その音から、あなたは彼らの能力に不安があり、彼らの仕事について未熟な方法で挑戦されていることに対処している少なくとも一人を扱っています。彼らはまた、彼らの仕事が悪い可能性が高いです-良い開発者は常に自己反映し、建設的な批判を受け入れ、彼らのやり方を変えることにオープンでなければなりません。

それが空になった今、あなたについて話しましょう。あなたが合理的だと思うかどうかに関係なく、あなたはボールを転がすためにこのような人々に特に注意する必要があります。これらの人々に対処するための最善の方法は、物事をどのように表現するかに非常に注意することです。

作成者ではなくコードを非難していることを確認してください。あなたのコードベースであるうんち山ではなく、手元にある1つの問題に焦点を当ててください。最初に戦闘を選択し、ユーザーに現れる重大な問題に焦点を当てて、発言しているすべてを却下するように仕向ける人に一斉に批判を投げかけないようにします。

ボディーランゲージと口調は、彼らと直接話し合っている場合に重要であり、あなたが言っていることを明確にし、彼らに話しかけたり、彼らの技術的能力を放棄したりしないようにしてください。彼らはほとんどの場合、すぐに防御側にいるので、あなたはそれらを確認するのではなく心配を解決する必要があります。あなたは、あなたが自分の側にいると無意識に思っているように、あまりにも自明ではなく、この会話について意識する必要があります。

これがうまくいかない場合は、もう少し攻撃的になります。製品が会議室から実行可能な場合は、コードレビュー中にプロジェクターで製品を持ち出し、バグを直接表示します。マネージャーがそこにいて、人が後戻りできないようにすると良いでしょう。これは彼らを恥じさせるためではなく、問題がユーザーにとって現実のものであり、コードに不満があるだけでなく、修正する必要があることを彼らに受け入れさせるためです。

最終的にどこにも行かず、その人を幼稚園の生徒のように扱うことにうんざりしていて、経営陣は問題を完全に認識しておらず、コードレビュアーとしてのパフォーマンスにあまり反映していないか、あなたの幸福を気にしている場合会社や製品の場合、上司とその行動について話し始める必要があります。できるだけ具体的かつ非人格的である-生産性と品質が損なわれているというビジネスケースを作成します。

コードレビューは有毒で、時間を浪費し、オタク戦争を生き抜こうとする意志があります。きれいなコードとコメント、命名規則、ユニットと統合のテスト、チェックイン戦略、RESTfulnessなどのようなものに関する意見の相違を見てください。

これを回避する唯一の方法は、コードレビューを渡すためのルールを書き留めることです。

その場合、チェックインに失敗したり承認したりする人ではありません。彼らは単にルールが守られていることを確認しているだけです。

そして、それらは前もって書き留められているので、コードを書くとき、ルールに従うことができ、あなたの推論を説明したり、後で議論したりする必要はありません。

ルールが気に入らない場合は、会議を開いて変更してください。

それは愛顧とみなされるかもしれないので、私はあなたのフィードバックをシュガーコートしません。

私の意見では、ベストプラクティスは常にコードに焦点を当て、作成者には決して焦点を当てないことです。

開発者レビューではなく、コードレビューです。

• 「このwhileループは決して終わらない」、「あなたのループは終わらない」
• 「シナリオXにはテストケースが必要です」ではなく、「このシナリオをカバーするテストを作成していません」

他の人とレビューについて話している間、同じルールを適用することも非常に重要です。

• 「アン、このコードについてどう思いますか？」ではなく、「アン、ジョンのコードについてどう思いますか？」

コードレビューはパフォーマンスレビューの時期ではありません-個別に行う必要があります。

これまでのところどの回答にも言及されていないことに驚いています。おそらくコードレビューの私の経験は異常なものですが、

単一のメッセージでマージリクエスト全体を確認するのはなぜですか？

コードレビューの私の経験はGitLab経由です。他のコードレビューツールも同様に機能すると考えていました。

コードレビューを行うとき、差分の特定の個々の行についてコメントします。これはコードに対するコメントであるため、個人的な批判として受け取られる可能性は非常に低いです。実際には、コードに対するコメントとして表示されます。

また、マージリクエスト全体についてコメントすることもできます。ただし、diffの特定の行に特定のポイントを指摘できます。（また、diffが変更されるように新しいコミットが追加されると、「古いdiff」のコメントはデフォルトで非表示になります。）

このワークフローにより、コードレビューはよりモジュール化され、凝集性が低くなります。コードレビューの行は、単に言うことができます、

素敵なアプローチ、これを専用の関数でラップします！

またはそれは言うかもしれません、

このオブジェクト名は、オブジェクトの目的と実際には一致しません。代わりに「XYZ」などの名前を使用できますか？

または、セクションに大きな問題がある場合は、次のように記述できます。

このコードが機能することはわかります（そしてなぜ機能するのかはわかります）が、理解するには集中的な研究が必要です。将来保守しやすくなるように、個別の機能にリファクタリングしてください。

（例：関数ABCは、実際には、fooをぶらぶらさせる、bozを禁止する、zorfをフリッピングする3つのことを行っています。これらはすべて別個の関数です。）

上記のすべてを書いた後、マージリクエスト全体について、次のような要約コメントを作成できます。

これは素晴らしい新機能であり、マージされると本当に便利になります。関数の命名をクリーンアップし、私が作成した個々のコメントに記載されているリファクタリングを処理してから、もう一度確認してください。:)

マージリクエストが完全な犬の朝食であったとしても、個々のコメントはそれぞれシンプルにすることができます。それらがさらに増えるでしょう。要約コメントは次のようになります。

申し訳ありませんが、このコードは実際には完璧ではありません。個々のコメントに詳述されているように、非常に多くのエッジケースがあり、これらは誤って処理され、ユーザーエクスペリエンスが低下したり、ある場合にはデータが破損したりします。（コミット438a95fb734のコメントを参照してください。）一部の通常のユースケースでも、アプリケーションのパフォーマンスが極端に低下します（somefile.cのdiffの個々のコメントに明記されている仕様）。

本番環境に対応するには、この機能を使用するには、フローのすべてのポイントで安全に行うことができる仮定に注意を払い、完全に書き直す必要があります。（ヒント：チェックされていない限り、仮定は安全ではありません。）

完全に書き換えられるまで、マージ要求を閉じます。

概要：コードの個々の行に対するコメントとして、コードの技術的な側面を確認します。次に、それらのコメントをマージリクエストの全体的なコメントにまとめます。個人的になるのではなく、事実と、コーダーではなく、コードについてのあなたの意見を扱ってください。そして、事実、正確な観察、理解に基づいて意見を述べてください。

誰もそれを取り上げなかったことに本当に驚きましたが、投稿されたサンプルレビューには何か問題があります。

ジョーに直接連絡しなければならない理由はまったくありません。ジョーが失敗を修正することは、あなたの仕事ではありません。その誰かはありません、あなたのビジネスです。あなたの懸念はコードの品質です。そのため、リクエスト/注文/デマンドを書く代わりに（もし私がジョーだったら、これが正当ではないので単純に拒否できます）、あなたの役割にとどまり、単純な匿名のtodoリストを書きます。

良い点と悪い点を公平に与えることは不可能であるだけでなく、あなたの役割から完全に外れています。

レビューから取得したコンテンツを使用した再編成の例を次に示します。

• Library \ ACME \ ExtractOrderMailクラスの変更を取得する前に、いくつかの問題を修正する必要があります。
• 私が何かを見逃さない限り、「TempFilesToDelete」は静的であってはなりません。
• 将来、関数を実行ごとに複数回呼び出すことがあります。これが必要な理由です（ここで何をする必要がありますか）。
• 「GetErrorMailBody」がパラメーターとして例外を受け取る理由を理解する必要があります。（そして、私はここで境界線になっています、今までに、あなたはすでに結論を出すべきだからです）
• SaveAndSendは、たとえば「SendErrorMail」のように、動作に合わせて名前を変更する必要があります
• コメントアウトしたコードは、読みやすくするために削除する必要があります。最終的なロールバックにはSubversionを使用します。

このようにレビューを定式化する場合、読者が個人的にどれほどあなたを嫌っていても、彼がここで見ることができるのは、誰かが後で続けなければならない改善に関するメモです。誰？いつ ？誰も気にしない。何 ？どうして ？あなたが言うべきこと。

次に、ヒューマンファクターを方程式から除外することにより、コードレビューが緊張を高めているまさにその理由に対処します。

コードレビューの全体的なポイントは、問題を見つけることです。ある場合はいずれかのバグは、あなたができる最善のことは、失敗しているテストケースを作成しています。

チーム（マネージャー）は、バグを作成することはゲームの一部であると伝える必要がありますが、バグを見つけて修正することで、みんなの仕事を節約できます。

定期的な会議（チームまたはペア）を開催し、いくつかの問題を経験することが役立つ場合があります。元のプログラマーは意図的に問題を導入しませんでしたが、時にはそれで十分だと思うかもしれません（時にはそれでさえ）。しかし、その2番目のペアを使用すると、完全に新鮮なビューが得られ、問題を調べることから大きく学ぶことができます。

それは本当に文化的なものであり、多くの信頼とコミュニケーションが必要です。そして、結果を扱う時間です。

レビューを行う前に、コーディング標準に関するコンセンサスを得ることが前向きなことだと思います。他の人は、入力があるときに何かをより多く購入する傾向があります。

命名規則のようなものについては、これが重要かどうかを他の人に尋ねてください。ほとんどの開発者は、特に仲間の間で同意します。プログラミングの世界でこれほど一般的なものに同意したくない人になりたいのは誰ですか？誰かのコードを選んで欠陥を指摘してプロセスを開始すると、非常に防御的になります。基準が確立されると、解釈や「十分に良い」と考えられるものに意見の相違が生じますが、現在よりも良い結果が得られます。

このプロセスの別の部分は、コードレビューが異議を処理する方法を決定することです。これは終わりのない議論になることはありません。ある時点で、誰かが決定を下さなければなりません。たぶん、裁判官になる第三者がいるか、レビュアーがすべての力を得ることができます。目標は成し遂げなければならないものです。

これの最後の部分は、コードレビューがあなたのアイデアではないことを皆に知らせることです、彼らは留まるつもりですので、誰もがそれを最大限に活用する努力をする必要があります。誰もが無力だと感じたら、コードをレビューすることを許可できるでしょうか？

うまくいけば、管理のための測定可能な結果がバグ、顧客の苦情、遅延などを制限することである。これに労力を注ぎました。

これは厳しいかもしれませんが、測定するものが何もない場合でも、良いフィードバックを与えることを心配しないでください。

ただし、将来的には、開発者がコードの改善を開始するときに、適切なフィードバックを提供する必要があります。コードの改善点を指摘する必要があります。また、チーム全体のメリットを指摘する必要があります。改善が見られるようになると、それらも同様に改善され、物事は徐々に始まり始めます。

別物; 彼らは発言権を持っていないように感じるので、防御的な空気があるかもしれません。お互いのコードをレビューさせてみませんか？具体的な質問をして、参加してみてください。それはあなたと彼らであるべきではありません。それはチームの努力でなければなりません。

1. 時間がある場合、このコードについて何を変更しますか？
2. コードベースのこの領域をどのように改善しますか？

今すぐそれを聞いて、そして今から6ヶ月後にそれを聞いてください。ここには学習体験があります。

要点-保証されていないコードの点では賞賛を与えないでください。しかし、努力を認め、間違いなく改善を認めます。レビューを敵対的なものではなく、チームの運動にするようにしてください。

緊張のない品質

コードについて肯定的なことを見つける方法を尋ねましたが、あなたの本当の質問は、「深刻な品質問題」に対処しながら「チーム内の緊張」を回避する方法です。

「悪いニュースを良いニュースに」挟むという古いトリックは裏目に出るかもしれません。開発者は、それが何であるか、つまり仕掛けのためにそれを見るでしょう。

組織のトップダウントラブル

あなたの上司は品質を確保するようにあなたに任せました。コード品質の基準のリストを思い付きました。今、あなたはあなたのチームに提供する積極的な強化のためのアイデアを求めています。

チームを幸せにするために必要なことを私たちに尋ねるのはなぜですか？チームに尋ねることを検討しましたか？

あなたは良い人になるために最善を尽くしているように聞こえます。問題は、メッセージをどのように配信するかではありません。問題は、通信が一方通行であるということです。

質の高い文化の構築

質の高い文化は、ボトムアップで成長するために育てられなければなりません。

品質が十分に向上していないことを懸念していることを上司に伝えてください。ハーバードビジネスレビューのアドバイスを適用してみてください。

チームと会いましょう。チームで見たい行動、謙虚さ、敬意、改善へのコミットメントをモデル化します。

「ご存知のように、[同僚]と私は、最近苦しんでいるような生産上の問題を防ぐために、コードの品質を確保する仕事をしていました。私は個人的にこの問題を解決したとは思わない。私の最大の過ちは、最初から皆さん全員を巻き込むことではなかったと思います。[同僚]と私はまだコード品質の管理に責任を負っていますが、今後は全員で品質の努力をしています。」

チームからコードの品質に関するアイデアを得る。（ホワイトボードが役立ちます。）終わりまでに要件が満たされるようにしてください。敬意を表して洞察を提供し、必要に応じて質問します。あなたのチームが重要だと感じていることに驚いて喜んでください。ビジネスニーズを損なうことなく、柔軟に対応します。

（恥ずかしい古いコードがある場合は、それを捨てて、誰もが率直になるように励ますかもしれません。最後に、人々にそれを書いたことを知らせてください。 ）

共同コードレビュー

数人の上級プログラマーがすべてのコードをレビューして修正するような、あなたが説明したような場所で働いたことはありません。あなたが自分の論文に赤いマークを付ける教師のように人々が反応するのも不思議ではありません。

アイデアを管理に販売できる場合は、ピアコードレビューを開始してください。これは、あなたや他の説明責任のある開発者を含む小グループで行うのが最適です。全員が敬意を持って扱われるようにします。

コードをピアレビューする重要な目標は、チームのすべてのメンバーがコードを理解できるようにすることです。不明瞭な関数名の例を考えてみましょう。関数名が混乱していることに気付いた後輩開発者から聞いた方が、上級開発者からの別の「修正」よりも受け入れやすい場合があります。

品質は旅です

他にすべきことの1つは、コードレビューが成功/失敗のようなものであるという概念を抹消することです。コードレビューの後、全員が何らかの編集を行うことを期待する必要があります。（そして、あなたの仕事は、それらが起こることを保証することです。）

しかし、それがうまくいかない場合...

質の高い文化を確立するためにいくつかの進歩を遂げたとしましょう。あなたはまだ全員を乗船させないかもしれません。それでも誰かが質の高いプログラムを使用していない場合、問題はチームの間に収まりきっていないことです。2人の間に問題があるということではありません。チームから解任する必要がある場合、チームの他のメンバーは理由をよりよく理解します。

もう1つの長い回答で申し訳ありませんが、他の人がこの問題の人間的な要素に完全に取り組んでいるとは思いません。

何かが特定の方法で実装された理由を尋ねることさえあります。悪いと思うときは、別の方法で開発していたと指摘します。

「なぜこのように実装したのですか？」の問題 開発者をすぐに防御側に置くということです。質問自体は、コンテキストに応じてあらゆる種類のものを暗示している可能性があります：あなたはより良い解決策を考えるにはあまりにも愚かですか？これはあなたができる最善ですか？このプロジェクトを台無しにしようとしていますか？あなたはあなたの仕事の質さえ気にしますか？など。コードが特定の方法で開発された「理由」を尋ねるのは対立的であり、コメントが持っていた教育的意図を覆すだけです。

同様に、「これを別の方法で行っていた...」も対立的です。なぜなら、開発者がすぐに考えるのは「まあ私はこの方法でやった... あなたはそれで問題を抱えたのですか？」それが必要であり、議論をコードの改善から遠ざけます。

例：

代わりに、「なぜ、あなたはこの値に一定の変数を使用しないことを選択したのか？」、単に状態は「このハードコーディングされた値が定数に置き換えてください尋ねるのXYZファイルにConstants.h質問をする」開発者が積極的に選択したことを示唆していない使用します定義済みの定数ですが、存在することさえ知らなかった可能性があります。コードベースが十分に大きい場合、各開発者が知らないことがたくさんあります。これは、その開発者がプロ​​ジェクトの定数に精通するための良い学習機会です。

コードレビューと一緒に歩くことの良いラインがあります：あなたが言うすべてをシュガーコートする必要がなく、悪いニュースを良いニュースで挟む必要がなく、打撃を和らげる必要がありません。それは私がいる文化かもしれませんが、同僚と私はコードレビューでお互いをcompめません-私たちが開発したコードの欠陥のない部分はpartsめ言葉で十分です。あなたがする必要があるのは、あなたが見た欠陥を特定し、おそらくその理由を明らかにすることです（それが明白/単純な場合、その理由はあまり有用ではありません）。

良い：

• 「この変数の名前は、コーディング標準に合わせて変更する必要があります。」

• 「この関数名の「b」は、PascalCaseにするために大文字にする必要があります。」

• 「この関数のコードは適切にインデントされていません。」

• 「このコードはにあるコードの複製であり、ABC::XYZ()代わりにその関数を使用する必要があります。」

• 「try-with-resourcesを使用して、エラーが発生した場合でも、この関数で適切に閉じられるようにする必要があります。」[ここにリンクを追加したのは、Java以外のユーザーがtry-with-resourcesの意味を理解できるようにするためです]

• 「この機能は、nパスの複雑さの基準を満たすためにリファクタリングする必要があります。」

悪い：

• 「変数名を標準に合わせて変更することで、このコードを改善できると思います」

• 「たぶん、try-with-resourceを使用して、この関数の内容を適切に閉じる方が良いでしょう」

• 「この関数のすべての条件をもう一度確認することが望ましい場合があります。そのNパスの複雑さは、標準の最大許容複雑さを超えています。」

• 「ここでのインデントは、標準の4つではなく2つのスペースなのはなぜですか？」

• 「n-pathの複雑さの基準を破る関数を書いたのはなぜですか？」

悪い説明では、イタリック体の部分は、人々が打撃を和らげたいときによく使用するものですが、コードレビューで実際に行うのは、自分自身を不確かに聞こえさせることです。レビュアーがコードの改善方法に確信を持てない場合、なぜ誰もあなたに耳を傾ける必要がありますか？

「良い」ステートメントは簡潔ですが、開発者を非難したり、開発者を攻撃したり、対立したり、欠陥が存在する理由を疑ったりしません。それが存在します; ここに修正があります。確かに、最後の「なぜ」の質問ほど対立的ではありません。

問題は次のとおりです。開発者はコードが批判されていることに不満を抱いています。しかし、それは問題ではありません。問題は、それらのコードが良くないことです（明らかにコードレビューが良いと仮定して）。

開発者が批判を集めているコードを好まない場合、解決策は簡単です。より良いコードを書く。あなたはコードの品質に深刻な問題があったと言います。より良いコードが必要であることを意味します。

「メソッドに意味のある名前を付ける必要があるのはなぜですか？」特に気がかりなものです。彼はそれが何をするか知っているか、少なくとも彼はそう言っているが、私は知らない。どのメソッドも、理にかなった名前を持っているだけでなく、コードの読者にそれが何をするのかをすぐに明確にする名前を持たなければなりません。AppleのWebサイトにアクセスして、Swift 2からSwift 3への変更に関するWWDCビデオを探してください。その種のビデオは、直感的なメソッド名が非常に重要であると考えるよりもはるかに賢い開発者であると開発者を説得するかもしれません。

別の不安なアイテムは、「バグレポートが顧客によって提出された後、彼女はバグを知っているが、開発者がそれを指摘するために彼女に怒っていることを恐れている」と私に言った同僚です。誤解がある可能性もありますが、バグを指摘して開発者が怒った場合、それは悪いことです。

私はあなたが説明したコードレビューの方法に敬意を持って反対します。2人のスタッフが「密室」に出て批判を浴びると、優れたコードレビューを避けるべきであるという敵対的な概念が制度化されます。

コードのレビューを可能な範囲で前向きな体験にすることは、コードを成功させるために不可欠です。ステップ1は、レビューという敵対的な概念を削除することです。毎週または隔週のグループイベントにします。参加を歓迎していることを全員が知っていることを確認してください。ピザやサンドイッチなど何でも注文できます。それが否定的な意味合いをかき立てる場合、それを「コードレビュー」とも呼ばないでください。祝うもの、奨励するもの、共有するものを見つけましょう。たとえそれが現在のスプリントやイテレーションの進歩に過ぎないとしてもです。レビューに交代でリーダーシップを割り当てます。

プロセスを、製品と人々に奉仕するための努力とする。それらが建設的かつ積極的に行われ、良い技術やパターンが共有され、貧しいものが落胆するのと同じように奨励されるなら、誰もが恩恵を受ける。誰もが公の場で指導を受けます。「理解していない」問題プログラマーがいる場合は、個人的にも個別に対処する必要があります。より広範なグループの前では決してしないでください。これはコードレビューとは別です。

何か「良い」ものを見つけるのに苦労しているなら、それは私に質問を請います：プロジェクトで進歩があり、人々が働いているなら、その進歩自体は祝うべきものです。あなたが本当に良いものを本当に見つけていない場合、それは最後のレビュー以降に行われたすべてが悪いか、ニュートラルより良いことを意味します。それは本当ですか？

詳細については、共通の標準が不可欠です。誰もが行われていることに関与します。また、より優れた新しい手法をコードベースに統合できるようにします。古い習慣を保証することを怠ると、「私たちは常にそのようにしてきた」という装いで決して切り捨てられません。

これらのすべてのポイントは、コードレビューが実装が不十分であり、経験不足またはスキルの低いプログラマを軽視するためのハンマーとして使用されるため、コードレビューに少し悪いラップが与えられ、誰にも役に立たないということです。このようにそれらを使用するマネージャーも、非常に効果的なマネージャーではない可能性があります。全員が参加者である優れたコードレビューは、製品、従業員、および会社すべてに役立ちます。

投稿の長さについては謝罪しますが、コードレビューがほとんど無視されていたグループに属していたため、保守不能なコードの遺産につながり、数年前のコードベースに変更を加えることを許可されたとしても狭い範囲の開発者しかいませんでした。それは私が再び横断しないことを選択した道でした。

優れたコードのパラドックスは、まったく目立たず、非常に簡単で簡単に記述できるように見えることです。この回答のプールプレーヤーの例は本当に気に入っています。コードレビューでは、不正なコードからのリファクタリングである場合を除いて、簡単に見直すことができます。

私はそれを探すことを強調します。コードをレビューしているときに、読みやすくて一見簡単に書けるようなファイルを処理した場合、「ここのメソッドが短くてきれいであるのが好き」など、適切なものをすぐに挿入します。 。

また、例を挙げてリードする必要があります。コードもレビューするように主張し、修正を受けたときのチームの動作をモデル化する必要があります。最も重要なことは、フィードバックに心から感謝することです。これは、あなたが提供できる一方的なフィードバックよりも大きな違いになります。

本当の問題は、すべてのコードレビューを行っているのは2人だけであり、その中から真剣に受け止めているのはあなただけであるということです。他のチームメンバーからの圧力。

より良い方法は、コードのレビューを行う責任をチーム全体に分散し、開発者にコードのレビューを行う人を選択させるなどして、全員がそれらに参加するようにすることです。これは、コードレビューツールでサポートする必要があるものです。

私はこれが直接起こるのを見たことがあり、感情的な知性に挑戦した答えからあなたを警告したい-彼らはチーム全体を殺すことができます。毎年新しい開発者を募集し、訓練し、正規化したい場合を除き、同僚と積極的な関係を築くことが不可欠です。結局のところ、これらのレビューを行ってコードの品質を改善し、そもそもコードの品質がより高い文化を育むことが大事ではないでしょうか？このコードレビューシステムをチームカルチャーに統合する手段として積極的な強化を提供することは、実際にあなたの仕事の一部であると主張します。

とにかく、コードレビューシステムをレビューする必要があるようですね。現時点では、レビューのプロセスのすべてが、客観的というよりも主観的なものである、または主観的なものとして解釈することができます。誰かがあなたのコードを好きではないからといって、コードをばらばらにしているような気がするとき、傷ついた気持ちになるのは簡単です。このように、オフィスカルチャーに適した方法で、追跡しやすく、コードシステムの（レビューシステムに関して）肯定的な改善を「祝福」します。

テクニカルリードはレビューセッションの外で集まり、コーディングガイドライン/コードレビューチェックリストを作成する必要があり、レビュー中にそれを遵守して参照する必要があります。これは、プロセスが発展するにつれて更新および改良できる生きたドキュメントでなければなりません。これらのTech Leadミーティングは、開発者がレビューの不一致がコードの結果であると感じずに、「物事を常に行ってきた方法」対「物事の新しい改善された方法」の議論が行われるべきです。最初のガイドラインが多少なりともスムーズになったら、開発者を積極的に強化する別の方法は、フィードバックを求めてから実際に行動を取ることです チームとしてプロセスを進化させると、オンボードのコードのレビューを開始できるようにスピードアップできるので、退職するまでレビューを行うのが面倒になりません。

施設...

プログラマーは問題解決者です。問題またはエラーが発生した場合、デバッグを開始するように条件付けられています。

コードはアウトライン形式のメディアです。フィードバックのために段落形式のナラティブに切り替えると、翻訳が必要な切断が発生します。必然的に何かが失われたり誤解されたりします。やむを得ず、校閲者はプログラマーの言語で話していません。

コンピューター生成のエラーメッセージはめったに質問されず、決して個人的なf辱とは見なされません。

コードレビューアイテムは、人間が生成したエラーメッセージです。それらは、プログラマーや自動化ツールが見逃しているエッジケースや、他のプログラムやデータへの避けられない副作用をキャッチすることを目的としています。

結論...

したがって、より多くのコードレビュー項目を自動化ツールに組み込むことができれば、それらはより良く受け取られます。

問題は、疑いのないままにするために、そのようなツールを、通常は毎日または毎週、継続的に更新して、手順、標準、および慣行のすべての変更に準拠する必要があるということです。マネージャーまたは開発者チームが変更を加えることを決定した場合、それを実施するにはツールを変更する必要があります。コードレビューアの仕事の多くは、ツールのルールを維持することになります。

サンプルコードレビューのフィードバック...

これらの手法を組み込んだ特定の例の書き直し：

• 件名：

  • Library \ ACME \ ExtractOrderMailクラス。

• 原則問題...

  • TempFilesToDeleteは静的です
    • GetMailsへの後続の呼び出しでは、ファイルが追加されますが、削除後に削除されることはないため、例外がスローされます。現在は1回しか呼び出していませんが、将来、並列処理を行うことでパフォーマンスが向上する可能性があります。
    • インスタンス変数としてTempFilesToDeleteを使用すると、複数のオブジェクトを並行して使用できます。
• 二次的な問題...
  • GetErrorMailBodyには例外パラメーターがあります
    • それ自体は例外をスローせず、これをToStringに渡すだけなので、必要ですか？
  • SaveAndSend名
    • 電子メールは今後これを報告するために使用される場合とされない場合があり、このコードには永続的なコピーを保存してエラーを報告するための一般的なロジックが含まれています。より一般的な名前は、依存メソッドに変更を加えることなく、このような予想される変更を許可します。1つの可能性はStoreAndReportです。
  • 古いコードをコメントアウトする
    • OBSOLETEとマークされた行を残すことはデバッグに非常に役立ちますが、「コメントの壁」は隣接するコードのエラーを隠すこともできます。Subversionにはまだあります。おそらく、Subversionの正確な場所を参照する単なるコメントでしょうか？

既存のコード（理解しやすいように聞こえます）について何か良いことを言えない場合は、開発者がコードの改善に関与するようにしてください。

機能変更またはバグ修正のためのパッチでは、同じパッチに他の変更（名前変更、リファクタリングなど）をバンドルすることは役に立ちません。バグを修正したり、機能を追加したりする変更を行う必要があります。

名前の変更、リファクタリング、およびその他の変更が示されている場合は、前または後に個別のパッチでそれらを行います。

• これはかなりいですが、他のすべての厄介なコードと一致していると思います。後でクリーンアップしましょう（理想的には、機能的な変更のないパッチで）。

  また、あなたがリファクタリングに参加する場合に役立ちます、と聞かせてそれらを見直し、あなたのコードを。それは、あなたが何かが悪いというよりむしろ良いと思う理由を言う機会を与え、また建設的な批判をうまくとる例を示す機会を与えます。

単体テストを新しい機能に追加する必要がある場合は、メインパッチに含まれます。ただし、バグを修正している場合、テストは前のパッチで行われ、合格ではなく、修正が実際にバグを修正したことを示すことができます。

理想的には、計画（修正をテストする方法、またはリファクタリングする対象と時期）について、作業を行う前に話し合う必要があります。そうすることで、問題に気付く前に何かに労力を費やしていません。

コードが想定される入力に対応していないことがわかった場合、開発者が合理的な入力と見なしているものと一致しない可能性もあります。可能であれば、事前に同意する。少なくとも、何に対処できるべきか、どのようにそれが失敗するのを許すことができるかについて、いくつかの議論があります。

技術的または簡単な解決策があると仮定するのは間違いだと思います。「同僚が自分の仕事を自分の基準で判断し、それを実施する力を持っていると動揺します」。

コードレビューは、良い点と悪い点の単なる議論ではありません。それらは暗黙のうちに「誰がヤードスティックを使用しているのか」、「誰が決定を下すのか」、したがって、ほとんど知らないうちにランクになっています。

これらの点に対処しないと、遭遇する問題のない方法でコードレビューを行うのが難しくなります。ここでそれを行う方法についていくつかの良いアドバイスがありますが、あなたは自分で難しいタスクを設定しました。

もしあなたが正しいなら、小刻みの部屋なしで、それを指摘することは攻撃です：誰かが台無しにします。そうでない場合：それを取得していない別のMBA。いずれにせよ、あなたは悪者になるだろう。

ただし、レビューの内容と理由が明確で同意されている場合、悪意のある人物ではない可能性が十分にあります。あなたはゲートキーパーではなく、単なる校正者です。この合意を得ることは解決が難しい問題です[1]。私はあなたにアドバイスをしたいのですが、私はまだそれのこつを持っていません...

[1]人々が「OK」と言ったか、それについての戦いをやめたからといって、それは解決されません。Xが{インテリジェンス、経験、マンパワー、締め切りなど}にとって実用的でないと言う人は誰もいませんが、それは実際にXを実行する特定のインスタンスになるとは限りません...

コードレビューは相互に行う必要があります。みんながみんなを批判しました。モットーを「怒らないで、平等に」としましょう。誰もが間違いを犯し、人々が自分のコードを修正する方法をホットショットに伝えると、彼らはこれが通常の手順であり、攻撃ではないことを理解します。

他の人のコードを見ることは教育的です。コードの弱点を指摘できるところまでコードを理解し、その弱点を説明することで多くのことが学べます！

全体のポイントは欠陥を見つけることなので、コードレビューには賞賛の余地はほとんどありません。ただし、修正を賞賛できます。適時性と清nさの両方を賞賛することができます。