コードレビューで肯定的なコメントをするのは適切ですか、それとも建設的な批判専用ですか?


36

私は最近多くのコードレビューを行ってきましたが、コードレビューに肯定的および/または面白いコメントを入れることの肯定的および否定的な効果とプロフェッショナリズムに自信がありません。

私たちのチームではコードレビュープラットフォームとしてGithubを使用しているため、コメントは誰でも見ることができます。私は通常、このプラットフォームを使用して、最初から最後までのプロセス全体が見えるようにし、歴史的なものにします。


はい、これは主に文化に関係していることを理解していますが、一般的な答えを探しています。
コードマン

22
肯定的なコメントで、見たいものを補強することが重要です。

2
それが適切かどうかはわかりませんが、レビューでコーディング俳句を投稿することがあります。ジュニアプログラマー-コメントのないコードは-痛みのかけらのようです。
ヤニス

私は実際にシニアプログラマーであり、シニアのコードをレビューしています-ここにはかなり厳密なプロセスがあり、すべてのコードをレビューする必要があります:)
マン

回答:


53

ポジティブだけでなくネガも強調することが重要です。特定の地獄のようなサブシステムのリファクタリングをきちんとしたクリーンなものにレビューしていれば、プログラマーの努力でおそらくピザを買うでしょう。

レビューをトレーニングとして使用している場合、それは二重に重要です-優れたコードを強調することは、そのコードをレビューするジュニアプログラマーにとっても役立ちます。特定のアプローチやテクニックが他のアプローチより優れている理由について質問する機会があります。


「なぜ重要なのか」についてメモを追加できますか?あなたがそうするとき、私は受け入れられたとマークします:)
コードマン

3
これにより、人々は自分がやっていること(良いコードを書くこと)が高く評価されていることを知ることができ、コードレビューの目的である成長に集中できます。
ジョナサンリッチ

1
これを答えに追加できますか?
コードマン

2
+1は、このバッジに最適な回答バッジに値します。建設的な批判を十分に評価していない場所の数は、常に私を驚かせます。良い仕事をしているときに良い仕事をしていることを人々に伝えることは、驚くほど効果的な動機付けになる可能性があります。
ベンジャミングリュンバウム

@ベンジャミン:コードレビューを「お互いのコードの欠陥を見つける」ラバースタンピングプロセスとして扱い、「高性能なチームを作る」としてではない組織が多すぎます。私の経験では、コードレビューは、ソフトウェアチームが実際に実行することを妨げる障壁を打破するための最速かつ最良の方法です。コメントの前に-2(修正する必要があります)から+2(すばらしい作業)までの注釈を付けるという標準の表記法があります。
-mattnz

8

おかしい:最小限の投与量を除き、ウォータークーラー用に保存してください-プルーンの顔を持つことはコードをレビューするための要件ではありません。

ポジティブ:確かに。レビューには、定義上、ポジティブとネガティブ/建設的の両方が含まれます。

ポジティブフィードバックはすべての人に役立ちます。

好意的な意見を受け取った人は、自信を強め、肯定的なフィードバックを通じて同じことをするよう促します。

残りについては、他の人が述べたように、彼らは何をすべきかだけでなく、何をすべきで ないかを学びます。また、彼らは優れていることを奨励されるので、彼らもいつか注目を集めることができます。

私はかつて前向きなフィードバックで寛大だったボスのために働いていました-その結果、チームは非常に成功し、生産的でした。彼は前進し、他の人が引き継いで、仕事を賞賛する能力が欠けていました。生産性と士気は急降下し、優秀なチームメンバーの多くが退社しました。


3

私は、文化のせいで、コメントを簡潔に、要点を保っておくと思います。

一部の人々が物事を間違った方法でとることを避けることはできません。
それを緩和するために、個人的な一対一の会話は、対面が不可能な場合、チャット、電子メール、またはスカイプで物事をスムーズにします。


1
いい視点ね。特に多言語、多文化環境では、コメントに「おかしい」ことは簡単に裏目に出る可能性があります。
デビッドナバラ

2

コードレビューのコメントは管理しています

コメントを管理ツールとして扱う

コードレビューにコメントを挿入することは、管理の一形態です。そのため、管理ツールとしてアプローチする必要があります。

コメントする際に管理慣行を使用する

目標が望ましい結果を達成することである人々を管理するための構造があります。管理への主なアプローチのいくつかはコメントには適用されませんが、ほとんどは適用されます。適用可能なトピックには、環境、リーダーシップ、組織、および管理が含まれます。

環境

文化

環境は管理のスタイルを決定します。管理ツールを使用する場合は、職場の文化と環境に留意する必要があります。通常、これは業界および管理対象の会社または事業体の規模の影響を受けます。

スタイル

気楽な文化があれば、それは使用されている管理のスタイルで出くわすかもしれません。非常に厳しいガイドライン、ポリシー、および結果がある場合は、使用するスタイルに反映する必要があります。だから、誰もがドロイドと弱い心を持ったストームトルーパーを参照するスターウォーズのジョークに参加しているなら、コメディの挿入が適用されるかもしれません。ただし、最終結果を真剣に受け取らないという悲惨な結果がある場合は、回避する必要があります。

リーダーシップ

基礎

コメントする際に考慮すべきリーダーシップの3つの柱があります。つまり、ビジョン、コミュニケーション、判断です。

Vision

説明や指示を行う際に壮大なビジョンを念頭に置くことが重要です。コメントでは、これは小さな変更がプロジェクト全体にどのように影響するか、異なるアプローチをとることの意味、または懸念の分離への帽子の先端を指摘することを意味します。

Communication

良いコミュニケーターであることは、人生の多くの面で重要です。コメントに違いはありません。賢明なレベルの簡潔さを採用することは重要です-特にコメントはスペースをとるべきではないので。早めにポイントを取得し、必要に応じて例を使用してバックアップします。大規模な組織では、問題が1つのレビューセッションにローカライズされていない場合、コミュニケまたはメモを送信する必要も含まれます。

Judgement

コメントを作成する必要があるかどうか、および変更の必要性を判断する際には、戦略を使用することが重要です。あなたの判断は常に正確である必要はありませんが、特に大規模な判断の呼び出しが行われる場合は特に一貫して正しい必要があります。

整理

管理の観点から、組織化とは、最終目標を念頭に置き、一連のルールに従うようにプロセスを調整することを指します。また、コメントは、設計の流れに沿っていることを確認するために、可能な場合は互いに構築する必要があるため、これに留意する必要があります。また、カップリングを減らし、全体的な設計に従うために、レビュー対象のコードの範囲に留意することも重要です。

制御

管理対象のアクションを制御することは微妙なプロセスです。しっかりしている一方で、人々が重要であることも念頭に置いておく必要があります。他の人をコントロールしながら使用する管理スキルがいくつかあります。これらのスキルは、政治的、概念的、対人的、診断的、技術的です。

政治的

政治は、人々の間に相互作用があるときはいつでも見つけることができます。これは大きなトピックですが、一般的な意味では、政治は影響を中心に展開します。コメントをするときは、職場での個人的および専門的な政治に留意することが重要です。これは、指示、ジョーク、または質問に関連している可能性があります。

概念的

概念化による管理は重要なツールです。手元の状況の複雑な分析が必要です。コメントする際には、レビューで示された結論または変更を導き出すために使用された分析の一部を含めることが有益である可能性があります。

対人関係

管理する際に対人スキルは非常に重要です。これも大きなトピックです。対人関係のスキルで考慮すべき重要なことのいくつかは、メンタリング、建設的な批判、および「ハープニング」です。

Mentoring

管理が拮抗薬としてよりもメンターとして見られることが重要です。コードレビューでは、これは、状況を改善するために使用できる設計パターンまたはアプローチにうなずきを含めることが有益な場合があることを意味します。

Constructive Criticism

批判は、反省を呼び起こすので重要です。しかし、批判は可能な限り積極的に行われるべきです。これは、批判を裏付ける有効な証拠を提供し、また、使用されるトーンが否定的でないことを保証することを意味します。コードをレビューする場合、これには、コード全体を交換する必要がある場合に間違った場所をすべて表示するのではなく、エラーを生成しながらエラーを生成する例外またはシナリオの表示が含まれます。

"Harpooning"

「ハープニング」とは、比someone的に誰かを地面に投げかけることです。これは、彼らが立ち上がることができないと感じるまで、猶予なしに段階的にそれらを分解することによって行われます。コードレビューや他の場所で人をharした場合、あなたは彼らの協力を失います。誰かを過度に破壊しないようにすることが重要です。


エグゼクティブサマリー

コードレビューのコメントを管理ツールとして扱います。コメントは簡潔で、要点を示し、建設的でなければならないことに留意してください。また、レビュー中の人にコメントするときに考慮されるようにします。


コードレビューは管理的なものであってはなりません。その他の名前は、正当な理由から「PEERレビュー」です。私が答えに持っている他の問題は、人ではなくレビュー中のコードであるはずだということです。コードレビューがその人のレビューとして扱われる場合、それは「人々を打ち負かす」ための管理ツールになります(または間もなく)。それがKPIの入力になり、
Peerが

@mattnz-ピアは互いに頻繁に管理します。さらに、すべての組織が厳密にトップダウンの階層で動作しているわけではありません。その場合、ピアは管理の重要な要素です。しかし、コードレビューは個人に関するものではないというあなたの主張には問題があります。悪いコーディング習慣を修正するには、実際のガイダンスが必要です。成功するためには、そのガイダンスを優雅で敬意を持って発行することが非常に重要です。
トラビスJ

@mattnz-また、コードレビューがその人のレビューであることを一度も暗示していないことに注意してください。私はあなたがここで受け入れられた答えを支持していることに気づきました。私もそれに同意します。しかし、奇妙なことに、答えは個人に明確に焦点を当て、ピザを購入し、個人的に賞賛を提供します。私はそれについて問題はありませんが、どうやってそれが「人のレビュー」であるとは言えませんか。正直に言うと、この答えの最初と最後の文しか読んでいないようです。
トラビスJ

0

コードレビューは、部分的に欠陥を発見することにより、コードの品質を改善するためのツールです。さらに重要なことは、優れたコーディングプラクティスを浸透させることです。

この観点から、うまくやったことについてコメントすることが重要です。トレーニングのコンテキストでは、改善点についてもコメントする必要があります。文化が継続的な改善の1つである場合、常に改善についてコメントする必要があります。

間違い、バグ、および不適切なコーディングが発生します。非個人的な方法でそれらを指摘し、期待どおりに扱います。

行動修正の観点から見ると、報酬は罰よりも変化を生み出すことにはるかに優れています。報酬として良い仕事に気づいたことを考えます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.