コードレビューにおける肯定的なフィードバックはどれほど重要ですか？

コードレビュー中にコードの良い部分とそれが良い理由を指摘することは重要ですか？肯定的なフィードバックは、レビュー対象の開発者にとっても、レビューに参加する他の開発者にとっても同様に有用です。

オンラインツールを使用してレビューを行っているため、開発者はコミットしたコードのレビューを開き、他の人は特定の期間（1週間など）にコードをレビューできます。他の人は、コードまたは他のレビューアのコメントにコメントできます。

正のフィードバックと負のフィードバックのバランスをとるべきですか？

ピアコードレビューを使用した品質と士気の向上
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

誰もがすべきこと：コードレビュー
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

これらの記事は両方とも、コードレビューの目的の1つは、エラーを見つけるだけでなく、優れた開発手法に関する知識を共有することであると述べています。

だから、それは非常に重要だと思います。誰が会議に行って、ただ批判されることを望みますか？

コードレビューを行うとき、実行中のモノローグを持っている傾向があるので、読んでいるものの意味を理解しているので、「わかりました、それが何をするかわかります。これに接続して呼び出します」それ、申し分なく..そしてその作品は、申し分なくそれらの両方に依存しています。」

このように「これはすごいすばらしい！」ではなく、まったくつまらない退屈なコードかもしれませんが、他の誰かが実際に解析して理解したことを聞くと、それ自体が肯定的なフィードバックの形であり、フィードバックは「このコードは理にかなっています」、理解できない部分に出会ったときは説明を求め、理解したら「ああ、わかった」と叫ぶ。

私たちは皆、コードを他者に理解してもらいたいと思っているので、理解の単純な転送は他のエンジニアに賞賛されると思います。

とはいえ、良いまたは肯定的な特性であるコードの部分を見た場合（それ自体の最小形式であれば、退屈な些細なコードでも良い場合があります）、私は間違いなくそれらの特性を述べる傾向があります。すばらしいです！" 「これは最小限の実装であると思う」または「わかりました、この複雑なアルゴリズムには多くのコメントがあります」というように、コードの属性に焦点を当てて、本来の良さや悪さではありません。

コードレビューのコードに「良さ」または「悪さ」を帰属させて、エンジニアがペデスタルを見下ろしたり、保持したりするのを避けるために、何かが良いか悪いかを言わず、むしろ彼らのコード。

「OKこの部分は理にかなっています。ああ、ここに魔法の数字があります。その値の意味は、これに触れる次のエンジニアによってよく理解されないかもしれません」

「ここにはDIコンテナがあります。そのため、そのリポジトリとの疎結合になります」

「ああ、静的な辞書があります。複数のスレッドがその辞書に触れていると、競合状態に陥ることがあります」

良いことも悪いことも言っているわけではありませんが、エンジニアがそれを変更すべきかどうかは、コードがレビューされているエンジニアによって理解されるでしょう。もちろん、コードレビューをイェイまたはネィで終わらせる必要がありますが、これらのステートメントをその過程で蓄積することで、「私は好きですこれをチェックインする前に修正されたマジックナンバー」。

コードレビューで私が本当に気に入っていて、「十分な」コードを超えたものを見つけた場合は、肯定的なフィードバックを提供します。

一般的に、誰かが実際にあなたに「わあ、これは本当に素晴らしい！」と言うようにするピースコードを書くと思う。はい、肯定的なフィードバックは重要です-それは著者が彼らがしたことを他の人が楽しんでいたことを著者に知らせ、彼らはそれをもう一度試してみるべきです。ただし、ガイドラインと標準的なプラクティスに従うだけではありません。誰かがうまくインデントしたり、定型的なコメントを追加したために賞賛を与えると、バーがかなり低くなる可能性があります。

これはプログラミングの問題ではなく、一般的な管理と人間の相互作用の問題です。コードレビューの肯定的なフィードバックは、あらゆる種類のレビューの肯定的なフィードバックとまったく同じくらい重要です。

これが必要であるかどうか（およびそれが必要な程度）は、話し相手の気質と感情的な構成の関数です。一部の人々は、それが賞賛と結びついている場合、修正にはるかに効果的に反応します。他の人は、修正を加えた場合、賞賛を不誠実と見なします。

一般的な式は、「フィードバックサンドイッチ」と呼ばれることもあります。最初に良いもの、次に悪いもの、最後に良いもの。考えは、全体的なトーンを正に保ちながら、同時に負のフィードバックが受信されるようにすることです。これは、レビューを予測する際のストレスを防ぎ、その後自己吸収されたひなを防ぐのに役立ちます。両方とも生産性と品質に関して非常に重要です。これは単なる感触的な感情的なホグウォッシュではありません。それは人間の行動101です。

繰り返しますが、あなたが働いている人を知り、彼らが何に反応するかを理解する必要があります。人々に対処することが経営の目的であり、優れたマネージャーは人々に対応させる方法を知っています。

正のフィードバックは非常に重要だと思いますが、それは主に個人的で現実的なダイナミクスによるものです。私たちは皆、何時間も、何日も、何週間も、何ヶ月も座ってコードを書きます。コードレビューはそれを紹介するチャンスです。

コードレビューに行って、期待できる最良の結果が「コメントなし」（つまり、肯定的なフィードバックのバランスがない）である場合、会議は簡単に「悪い人があなたの吸うと思う方法を見つける」というタイトルになります。その結果、開発者はコードレビューに悩まされるか、恐ろしいコードレビューに悩まされるようになります。これは明らかにチームにとって不利益です。開発者は、コードをレビューすることを「忘れる」か、学習された無力感を開発し、これらの会議で爆発を避けるために、あらゆる小さなことについて何をすべきかを絶えず批評家に尋ねます。

理論的には、悪い人を直し、全員に感情をドアに残してもらうように依頼するのが最も論理的であると言うことはすべて良いことですが、それはまさに、担当者の開発者が対人関係の耳が聞こえないものとして受ける責任と同じような態度です。理論はさておき、私たちは人間です。それは重要です。

サイドバイサイドまたはチームレビューを行う場合はさらに重要です。書面によるレビューでは、良いニュースはありません。目標は、コードを実稼働に移行することです。それがあなたのコードであるとき、あなたはあなた自身について気分が良いはずです。

コードレビューは、チームの指導と管理に役立つ情報源として使用する必要があります。コードレビューデータベースを乱雑にすることなく、肯定的なフィードバックを提供する機会がたくさんあります。サンプルを引き出して、他のユーザーと共有できます。

開発者のレビューには、コード以外にも多くのことがあります。コードレビュー時間をハイジャックすると、アプリを公開するのに逆効果になる可能性があります。コードレビュー以外の開発者を支援するために固有の時間を設定しますが、コードレビューのフィードバックを除外する必要があるという意味ではありません。

「バックハンドの賛辞」を避けることに注意を払わない限り、コードに関する肯定的なフィードバックを提供することであなたを裏切る可能性があると私が考えることができる唯一の方法です。ほとんどの人はこれに精通しています...「素晴らしい仕事ですが...」などのフレーズで表されています

これがプログラマの個人的なレビューではなく、システム全体の品質のためにコーディングの実践を改善する努力であるという態度で全員が会議に参加する場合、すべてのフィードバックは「良い」フィードバックです。コーディングの実践を改善する方法を強調するフィードバックは、問題を処理するための有用な新しい方法を強調するフィードバックと同じくらい重要になります。

少なくとも、その長さに行かない場合、レビュープロセス内で「良いフィードバック、悪いフィードバック、良いフィードバック、悪いフィードバック」サイクルを実行しようと努力することは、同じバックハンドのliめ言葉。良いフィードバックを強要したり、努力を強化したり、知識の穴を埋めようとしないでください。

長年にわたって私が最も学んだフレーズ：

• 「これは興味深いアプローチです。[その他のユースケース]に対応する必要がある場合はどうなりますか？」
• 「いいね！すでにそれを行う方法があることをご存知ですか。どのアプローチがより効率的かを確認するためにベンチマークを行う必要があるかもしれません。」

コードレビューで最も気に入ったワークフローは次のとおりです。

1. 開発者はメーリングリスト/オンラインツールでパッチを提出します。
2. 気にする必要がある人は誰でもパッチを見て、改善を提案します。
3. 開発者は＃1に戻ります
4. 改善が必要ない場合、人々は「お疲れ様でした」と言います。<-正のフィードバック。受け入れられるコードはすべて良好です。人々が物事を変えるようにあなたに言う必要が少なくなればなるほど、あなたはうまくやっています。
5. 開発者がコミットし、次の項目に進みます。

通常、新しい開発者はコードベースに慣れるにつれて、より多くの「修正」フィードバックを得ることになります。

このアプローチの利点は次のとおりです。

1. 誰もが何をしているかを知っています。独占やミステリーのコミットに関する知識はありません。
2. 誰もが他者のフィードバックから学びます。これは重要。ペアリング中に対面の会話で2人の間でのみフィードバックが発生する場合、部屋の反対側の誰かがメーリングリストで発生した場合と同じように利益を得ることができません。
3. 他の開発者は通常、バージョン管理の前にいくつかのバグを見つけることができます。

私はこれにまったく同意できません。Good Development Techniquesと、素晴らしいが不可解なものから単なる人間のコードを書くことができる、いわゆるNinja Codersとの違いは何ですか？ソフトウェア開発（IMO）は、保守性と理解しやすさを優先して、センスとunningさを避けるための最も一般的な分母の分野です。リスクが高すぎます。

レビューでコードを見て、「ああ、それはクールだ」と思う時間は考えられません。このようなコードに出会った場合、Cool-Yet-Unacceptableのキャンプに入るだろうと推測できます。

また、積極的なフィードバックが得られない人にも問題があり、おそらく一生懸命に努力し、最終的に「Trust me、it！」と混乱させます。

コードレビューは、チームにコード品質の責任を分散させるためにあります。つまり、後で重大な問題が発生した場合、個々の開発者を責めることはできません。問題を見つけるために使用し、それを維持する必要が生じた場合に備えて、奇妙なものの元の開発者から説明を得るために使用します。個人的には、負のフィードバックを受け取ることに興味があります。顧客はコードのクールさを気にせず、自分の望むことをするだけです。

バックスラップはパブに任せます。

それは私にとって重要でした。ポジティブのために、綿密なコメントやポジティブを望まない。私が書いたコードがすべて安っぽい場合は、その理由を教えて、修正して学習しましょう。しかし、私が正しいことをするなら、それを時々聞くのは良いことです。「正しかった」すべてのことを積極的に強化する必要はありませんが、「X、Y、Zを改善しましょうが、それ以外は良さそう」であっても重要です。

正直なフィードバックほど重要ではありません。私は大規模な金融会社で働いており、プログラマーが一生懸命努力しているのか、良い人であるのか、通常は良いコードを書くのか、顧客は気にしません！動作するソフトウェアが必要です。

完全に客観的であることが重要だと思います。肯定的なコメントをすることで士気を高めようとすることは、時間の無駄です。

これは、コードレビューが過度に重要であることを意味しますが、それがポイントではありません。また、自分自身を批判する必要があります。私が書いたコードはおそらく完全なゴミであり、間違いなく改善できるという仮定が、コードとスキルレベルを改善するように駆り立てることに気付きました。

コメントがない場合は、良い仕事をしたと考えることができます。

Mantraはシンプルです。高品質のコード（実際にはそれほどではない）が必要な場合は、適切なレビュー方法を実践する必要があります。そうは言っても、肯定的なフィードバックは、開発者/プログラマーがアイデア/解決策/修正を考え、思い付くのに役立ちます。厳しすぎることはしないでください。Q＆Aマネージャーは、チーム（またはメンバー）を正しい方向に導くことができるように、優れた方法論と実践を知っている必要があります。これにより品質が向上します。期間。

コードがコンペティション用であるか、就職の面接のために提出された場合（言い換えると、書かれていて書き換えできないコード）、肯定的なコメントは必須です。実際、負のフィードバックだけでなく、正のフィードバック（可能な場合）があることを確認する必要があります。そのようにして、コーダーは自分の長所と短所がどこにあるかを知り、それを補うことができます。

ただし、コードを書き直すことができる職場環境で話しているようです。その場合、システムのバグを徹底的に排除しようとしています。したがって、そのような状況では、マイナスのバグのみが価値があります。

気に入らない場合は、毎週コードレビュー会議を開いて、全員が良いコードと悪いコードの両方について話し合うことができます。

編集：私は言うが、何かがあなたを十分に感動させるならば、あなたが直接あなたの賞賛を表現するのを止めるものは何もない。ただし、トラッカーは生産コードのレビュー専用です。