津田  直子

津田 直子

1642569900

効果的なコードレビューを書くための10のヒント

私たちは皆、コードが行き来し続け、最終的にマージされるまでに数回の反復が必要なコードレビューを見てきました。

レビューがコードを受け入れないことは著者にとって迷惑であるだけでなく、著者が単に「それを理解していない」と考えるレビュー担当者にとっても迷惑です。

しかし、いくつかの良いニュース。フィードバックがスムーズに受け取られ、プロセスがより速く進むのは、変更の作成者だけではありません。レビュー担当者が展開できるいくつかの優れたプラクティスもあり、より鈍く、より明確なレビュープロセスを保証します。

効果的なコードレビューは、誰にとってもメリットがあります。理由は次のとおりです。

  • 作成者はフィードバックをより明確に理解するため、コード変更の反復が少なくなります。
  • コードベース全体へのアプローチに影響を与えることを検討するためのヒントとポイントを作成者に提供するので、次のコードベースでの「間違い」が少なくなります。
  • 作業はより迅速にマージされ、潜在的な他の作業のブロックが解除されます。
  • 少なくとも、実装の選択について質の高い議論が行われます。

この記事では、コードレビューの実施方法や、その際に注意すべき点については説明していません。代わりに、レビュープロセスに関するアプローチ行動に関するヒントと経験則をここに示します。したがって、すでに作業でコードを定期的にレビューしている場合、この記事は、いくつかのプラクティスを再考し、より良いレビューアになるのに役立つことを目的としています。

それを手に入れましょう。

1.常に理由を言う

いくつかの潜在的なレビューコメントを見てみましょう:

bad function name

this shouldn't be here

I think this might break

これらのコメントにはいくつか問題がありますが、最も顕著な問題は、それらが推論を提供しないことです。これらのコメントから、コードの作成者は自分のコードの何が悪いのかを推測することしかできず、私たちは皆、仮定がいかに悪いかを知っています—特にこの場合。

  • 作者は、名前/コードが間違っている理由について間違った結論に到達し、間違った修正を実装する可能性があります。これにより、レビューがさらに繰り返されることは間違いありません。
  • 作者は、名前/コードが間違っている理由についての知識に基づいたフィードバックを受け取りません。そうでなければ、彼らはおそらく彼らが知らなかった何かを学ぶか、彼らがすぐに見なかった何かを見ることによって彼らの視野を広げるでしょう。

はるかに良いコメントは何でしょうか?例を確認してみましょう。

This function name isn't ideal; it should start with a verb to indicate action, and in this case have an indication of the argument, maybe with something like '...ByUserId'. Remember to check our code style docs for more details on this

はい、あなたはもっとたくさんの単語を書いただけですが、あなたは今、彼らの名前の何が間違っているのか、そして彼らが関数名を考えているときに彼らがそれをどうするべきかを著者にはっきりと伝えました。

次回同じ作成者からコードレビューが送信され、その作成者が関数名の正しいルールに従っていることがわかると、どれほど素晴らしい気分になるか知っていますか?試してみる!

2.徹底する

コードの作成者は、コードベースのすべての出入りを知っているチームの最上級の人物、または最初のコードレビューを提出している新入社員である可能性があります。

これは、コードレビューの品質や徹底性に影響を与えるべきではありません。また、あなたが彼らの仕事を信頼しているという理由だけで、上級従業員にたるみを与えるべきではありません。

コードレビューは、コードの品質と構造を保証するだけでなく、作成者が見落としている可能性のあるコーナーケースやバグ、あるいは単にランダムなタイプミスを探すことでもあります。

そしてそれを認めてください、それは私たちの最善に起こります。バグを本番環境に移行する前に(さらにはステージングに移行する前に)キャッチする方が、バグを見つけて報告し、原因を見つけて問題を修正し、別のコードレビューに送信するよりも常に効率的です。

3.完全な結果を出さないでください

コードのレビュー担当者が変更された場合、問題を検出したときにコードを修正したり、解決策を考え出したりするのはあなたの仕事ではありません。

はい、あなたはあなたのアイデアを助けたり話し合ったりすることができます(そして時々そうすべきです)が、それはあなたが問題に完全な解決策を与えるべきだという意味ではありません。次のようなコメントを考えてみましょう。

this method doesn't quite do the job, it should be something like:
```
<code here>
```

これを行うと、コードの開発者はあなたの提案からほとんど学びません。場合によっては、ソリューションをコピーして貼り付け、詳細に考えずにざっと目を通すことがあります。

特に、これを常に行うと、開発者は簡単に怠惰になり、複雑なコードを書くときにあまり考慮しなくなり、レビュー担当者が何か問題を見つけた場合に修正を提案すると考えます。これを定期的に行う場合、チーム内のコード変更のレビュー担当者として頻繁に選ばれることに驚かないでください。

この場合の正しい動作は、代わりにメソッドがどのように見えるかを記述することです。なぜそれがうまくいかないのか、そして目前の問題にどのように取り組むのかを述べるべきであり、多分それを段階的に書き留めてください。場合によっては、一部の擬似コードでも問題ありません。ソリューションをコピーして貼り付けるだけでなく、開発者に提案されたアプローチについて実際に考えさせる限り、あなたは問題ありません。

4.レビューを延期しないでください

どのような種類のチームでも、特にエンジニアリングチームでは、お互いの作業を妨げないことが非常に重要です。

開発者がコンテキストを切り替えるのは簡単な作業ではありません。そして、問題の1つに関するコードレビューを待っていると、レビューを取得してコメントに対処しているときに、別のストーリーに切り替えて作業を行ったり、行ったり来たりする必要があります。

これは、レビューが非常に高速に行われる場合でも、とにかく発生します。開発者は次のタスクに進みたいと思うからです。ただし、レビューが長引くほど、開発者はブランチ間を行き来するこのように管理し、コードを再読み込みし(ここでもコンテキストスイッチ)、マージの競合を解決する必要があります。 。

また、実際にその人の作業をブロックすると想像してください。つまり、この機能が完成するか、コードの変更がマージされるまで、作業を続行することはできません。その場合、あなたがレビューを終えるまで、彼らは文字通り働くことができません。このすべては非効率的であり、両方の当事者にとって迷惑です(なぜなら、開発者はおそらく30分ごとにレビュー担当者にメッセージを送信し、ブロックされたらレビューを求めます🙃)。

このような混乱に道を譲らないようにするために、スケジュールでコードレビューを優先することは常に良い習慣です。もちろん、より緊急の作業が必要な場合や、すぐにレビューに取り組むことができるとは限らない場合もありますが、自分の作業とレビューの適切なバランスを見つける必要があります。

多くの人のコードをレビューする責任がある場合は、毎日スケジュールの時間枠をコードレビュー専用にし、その時間帯にのみ焦点を合わせます(または、複数の反復をより迅速に処理するために2つのスロット)。

5.ガイドラインに従ってください

チームが大規模であるか、十分に構造化されている場合は、プロジェクト/コードベースのコードを作成するためのガイドラインを説明するガイドラインがナレッジベースに作成されている可能性があります。

これには、コード編成、命名規則、および多くの設計上の選択に対する一般的なアプローチを含めることができます。あなたが積極的にコードを書き、他の人のコードをレビューしているなら、あなたはおそらくこれらのガイドラインに慣れているでしょう。

ただし、ガイドラインに戻って、数週間ごとまたは毎月、簡単に読んでみてください。コードレビューで忘れた点や注意を払っていなかった点がいくつあるかを見て驚かれることでしょう。

チームにそのようなガイドラインがない場合は、コードを確認しながらガイドラインを作成することをお勧めします。ほんの2、3のコードレビューで、レビュー中に注意を払っているポイントの長いリストを確実に思い付くでしょう。

さらに重要なことに、このようなガイドラインのリストは、チーム内の信頼できる唯一の情報源として機能し、すべてのコード作成者とレビュー担当者がコードを作成/更新/読み取るときに確認できるリソースを確保します。

6.良いコードを称賛する

コードレビューは必ずしも悪いニュースについてではありません。時々、作者に感謝するようなコードに出くわすことがあります。ロジックの一部、非常に効率的なクエリ最適化、または優れたUX。言ってください。

関連するコードに、nice!好きなことを述べた文章を使って、または長い文章でコメントすることができます。いずれにせよ、その人は感謝されていると感じるでしょう、そしてそれは間違いなくチームワークに違いをもたらします。また、コードの残りの部分がそれほど良くない場合でも、レビュー後にあまり気分が悪くなることはありません。

これらすべてに加えて、作成者は自分が書いた作品が実際に優れていることを検証したので、将来的にそのようなコンテンツを作成したり、他の問題について同様の手順を実行したりできます。

7.謙虚で前向きになる

何年にもわたって、私は読んだthis is stupid、または単にno。悪い日にもそれらのいくつかを書いたかもしれません。

理由等を述べる上記の点は言うまでもなく、そのようなコメントは単に不快で落胆させるものであり、いかなる種類の価値も生み出しません。Gitlabは、さらに読みたい場合にこれに関するいくつかの優れたヒントを提供します。これは、「ポジティブインテント」という会社の価値観と非常に一致しているように聞こえます。

簡単に言えば、レビューのコメントに親切で、相手の時間と仕事を尊重し、コードを書いている間、彼らが最善を尽くしていたと想定することは有益です。コードレビューで自慢したり、屈辱を与えたり、怒ったりすることにはまったくメリットがありません。

以前のコードレビューからコピーした実際の例をいくつか見てみましょう。文の調子を整えている言葉に注意してください。

- shouldn’t this be taking "value" as well 🤔
- maybe you can use "find" instead
- I think start the name with "get..."
- "Synchronize" sounds weird here imho.
- please add an empty line here

私を信じてください、少しimhoまたは「🤔」は大いに役立ちます。

8.リソースを指摘する

私の最初のフロントエンドの日のコードレビューで、cssプロパティの順序付けに関するこのリンクを何回共有したかはわかりません(おそらくstylelintを構成したばかりです🙈)。ある時点でブックマークにもあったと思います。

コードの作成者が問題を解決するのに役立つことがわかっているリソースがある場合は、コメントにリンクしてください。多くの場合、彼らはコメントを高く評価し、それが彼らの仕事で定期的に使用するためのリソースになるかもしれません。このリソースは、大きなリソースがあり、情報を検出するのが難しい場合は、会社のガイドラインの特定のセクションにすることもできます。

おそらく、あなたが指摘できるさらに重要なリソースは、作者が取り組んでいるコードベース内にあります。過去に他の誰かによってすでに実装された同様のロジックまたはコンポーネントは、作成者にとって優れたガイドになる可能性があり、コードベースの特定のセクションを以前に使用したことがない場合は、そのセクションを知らない可能性があります。

改善が必要なコードを検出し、同様の部分が以前に作成されたことがわかっている場合は、作成者がそれを見つけることを知っていると思い込まないでください。コメントでそれを指摘して、作成者が自分のコードを既存のコードと比較したり、改善したり、必要に応じて同じ規則に従うことができるようにします。

9.それはあなたではなく、彼らです

レビューのためにコードを読むときは、それを簡単に理解できることが不可欠です。コードの一部がぎこちないものである場合でも、コードを十分に注意深く読んでいないことに責任があるという意味ではありません。それどころか、それはコードが十分に明確ではないことを意味します。

そのチャンクが何をするのか理解するのに問題がある場合、将来、他の開発者がコードのその部分に触れる必要があるときに、他の開発者をフォローするのは難しいでしょう。そのようなコードを見つけたら、遠慮なく声を上げてください。そして、そのコードチャンクを説明するように作者に依頼するのではなく、代わりに書き直しを依頼してください

本当にもっと明確な方法で書くことができない場合は、少なくとも作者にコードにコメントを追加するように依頼してください。コードの目的を理解するために質問をして、代替アプローチを提案し、解決策について話し合うことができますが、応答に満足するだけでなく、マージされるコードが簡単に理解できるようにする必要があります。

10.あなたはいつも道ではありません

通常、物事を達成する方法は複数あります。コードの一部を読むとき、それを行う他の方法を想像する可能性が高く、それがより良い解決策であるため、コメントでそれを提案する傾向を感じるでしょう。時々あなたは自分自身に尋ねる必要があります:それは本当により良い解決策ですか?それとも、作者のやり方も良いのですが、提案はあなたがいつもやっているやり方に近いですか?

コードの複雑さや可読性に明らかな利点がない限り、書き直しを提案する前によく考えてください。コードを読み直して、チームの規則とコードスタイルに沿っていること、それがうまく機能していることを確認し、それがコードの品質にどのように影響するかを確認するために、考えている別のコードと比較してください。作者のやり方は大丈夫ですが、それでも自分のやり方の方が良いと思う場合は、必須の変更ではなく提案として書いて、提案している変更の理由と詳細について作者と話し合ってください。

これらのヒントが、より効果的なコードレビューアになり、長期的には、コードの作成者、およびチーム全体の時間を節約するのに役立つことを願っています。上記について何か考えがある場合、またはコードをレビューするときに役立つ可能性のあるその他の提案があれば、コメントで知らせてください。 

リンク:https ://betterprogramming.pub/10-tips-to-write-effective-code-reviews-c25c25aa22c5

#code 

What is GEEK

Buddha Community

効果的なコードレビューを書くための10のヒント
津田  直子

津田 直子

1642569900

効果的なコードレビューを書くための10のヒント

私たちは皆、コードが行き来し続け、最終的にマージされるまでに数回の反復が必要なコードレビューを見てきました。

レビューがコードを受け入れないことは著者にとって迷惑であるだけでなく、著者が単に「それを理解していない」と考えるレビュー担当者にとっても迷惑です。

しかし、いくつかの良いニュース。フィードバックがスムーズに受け取られ、プロセスがより速く進むのは、変更の作成者だけではありません。レビュー担当者が展開できるいくつかの優れたプラクティスもあり、より鈍く、より明確なレビュープロセスを保証します。

効果的なコードレビューは、誰にとってもメリットがあります。理由は次のとおりです。

  • 作成者はフィードバックをより明確に理解するため、コード変更の反復が少なくなります。
  • コードベース全体へのアプローチに影響を与えることを検討するためのヒントとポイントを作成者に提供するので、次のコードベースでの「間違い」が少なくなります。
  • 作業はより迅速にマージされ、潜在的な他の作業のブロックが解除されます。
  • 少なくとも、実装の選択について質の高い議論が行われます。

この記事では、コードレビューの実施方法や、その際に注意すべき点については説明していません。代わりに、レビュープロセスに関するアプローチ行動に関するヒントと経験則をここに示します。したがって、すでに作業でコードを定期的にレビューしている場合、この記事は、いくつかのプラクティスを再考し、より良いレビューアになるのに役立つことを目的としています。

それを手に入れましょう。

1.常に理由を言う

いくつかの潜在的なレビューコメントを見てみましょう:

bad function name

this shouldn't be here

I think this might break

これらのコメントにはいくつか問題がありますが、最も顕著な問題は、それらが推論を提供しないことです。これらのコメントから、コードの作成者は自分のコードの何が悪いのかを推測することしかできず、私たちは皆、仮定がいかに悪いかを知っています—特にこの場合。

  • 作者は、名前/コードが間違っている理由について間違った結論に到達し、間違った修正を実装する可能性があります。これにより、レビューがさらに繰り返されることは間違いありません。
  • 作者は、名前/コードが間違っている理由についての知識に基づいたフィードバックを受け取りません。そうでなければ、彼らはおそらく彼らが知らなかった何かを学ぶか、彼らがすぐに見なかった何かを見ることによって彼らの視野を広げるでしょう。

はるかに良いコメントは何でしょうか?例を確認してみましょう。

This function name isn't ideal; it should start with a verb to indicate action, and in this case have an indication of the argument, maybe with something like '...ByUserId'. Remember to check our code style docs for more details on this

はい、あなたはもっとたくさんの単語を書いただけですが、あなたは今、彼らの名前の何が間違っているのか、そして彼らが関数名を考えているときに彼らがそれをどうするべきかを著者にはっきりと伝えました。

次回同じ作成者からコードレビューが送信され、その作成者が関数名の正しいルールに従っていることがわかると、どれほど素晴らしい気分になるか知っていますか?試してみる!

2.徹底する

コードの作成者は、コードベースのすべての出入りを知っているチームの最上級の人物、または最初のコードレビューを提出している新入社員である可能性があります。

これは、コードレビューの品質や徹底性に影響を与えるべきではありません。また、あなたが彼らの仕事を信頼しているという理由だけで、上級従業員にたるみを与えるべきではありません。

コードレビューは、コードの品質と構造を保証するだけでなく、作成者が見落としている可能性のあるコーナーケースやバグ、あるいは単にランダムなタイプミスを探すことでもあります。

そしてそれを認めてください、それは私たちの最善に起こります。バグを本番環境に移行する前に(さらにはステージングに移行する前に)キャッチする方が、バグを見つけて報告し、原因を見つけて問題を修正し、別のコードレビューに送信するよりも常に効率的です。

3.完全な結果を出さないでください

コードのレビュー担当者が変更された場合、問題を検出したときにコードを修正したり、解決策を考え出したりするのはあなたの仕事ではありません。

はい、あなたはあなたのアイデアを助けたり話し合ったりすることができます(そして時々そうすべきです)が、それはあなたが問題に完全な解決策を与えるべきだという意味ではありません。次のようなコメントを考えてみましょう。

this method doesn't quite do the job, it should be something like:
```
<code here>
```

これを行うと、コードの開発者はあなたの提案からほとんど学びません。場合によっては、ソリューションをコピーして貼り付け、詳細に考えずにざっと目を通すことがあります。

特に、これを常に行うと、開発者は簡単に怠惰になり、複雑なコードを書くときにあまり考慮しなくなり、レビュー担当者が何か問題を見つけた場合に修正を提案すると考えます。これを定期的に行う場合、チーム内のコード変更のレビュー担当者として頻繁に選ばれることに驚かないでください。

この場合の正しい動作は、代わりにメソッドがどのように見えるかを記述することです。なぜそれがうまくいかないのか、そして目前の問題にどのように取り組むのかを述べるべきであり、多分それを段階的に書き留めてください。場合によっては、一部の擬似コードでも問題ありません。ソリューションをコピーして貼り付けるだけでなく、開発者に提案されたアプローチについて実際に考えさせる限り、あなたは問題ありません。

4.レビューを延期しないでください

どのような種類のチームでも、特にエンジニアリングチームでは、お互いの作業を妨げないことが非常に重要です。

開発者がコンテキストを切り替えるのは簡単な作業ではありません。そして、問題の1つに関するコードレビューを待っていると、レビューを取得してコメントに対処しているときに、別のストーリーに切り替えて作業を行ったり、行ったり来たりする必要があります。

これは、レビューが非常に高速に行われる場合でも、とにかく発生します。開発者は次のタスクに進みたいと思うからです。ただし、レビューが長引くほど、開発者はブランチ間を行き来するこのように管理し、コードを再読み込みし(ここでもコンテキストスイッチ)、マージの競合を解決する必要があります。 。

また、実際にその人の作業をブロックすると想像してください。つまり、この機能が完成するか、コードの変更がマージされるまで、作業を続行することはできません。その場合、あなたがレビューを終えるまで、彼らは文字通り働くことができません。このすべては非効率的であり、両方の当事者にとって迷惑です(なぜなら、開発者はおそらく30分ごとにレビュー担当者にメッセージを送信し、ブロックされたらレビューを求めます🙃)。

このような混乱に道を譲らないようにするために、スケジュールでコードレビューを優先することは常に良い習慣です。もちろん、より緊急の作業が必要な場合や、すぐにレビューに取り組むことができるとは限らない場合もありますが、自分の作業とレビューの適切なバランスを見つける必要があります。

多くの人のコードをレビューする責任がある場合は、毎日スケジュールの時間枠をコードレビュー専用にし、その時間帯にのみ焦点を合わせます(または、複数の反復をより迅速に処理するために2つのスロット)。

5.ガイドラインに従ってください

チームが大規模であるか、十分に構造化されている場合は、プロジェクト/コードベースのコードを作成するためのガイドラインを説明するガイドラインがナレッジベースに作成されている可能性があります。

これには、コード編成、命名規則、および多くの設計上の選択に対する一般的なアプローチを含めることができます。あなたが積極的にコードを書き、他の人のコードをレビューしているなら、あなたはおそらくこれらのガイドラインに慣れているでしょう。

ただし、ガイドラインに戻って、数週間ごとまたは毎月、簡単に読んでみてください。コードレビューで忘れた点や注意を払っていなかった点がいくつあるかを見て驚かれることでしょう。

チームにそのようなガイドラインがない場合は、コードを確認しながらガイドラインを作成することをお勧めします。ほんの2、3のコードレビューで、レビュー中に注意を払っているポイントの長いリストを確実に思い付くでしょう。

さらに重要なことに、このようなガイドラインのリストは、チーム内の信頼できる唯一の情報源として機能し、すべてのコード作成者とレビュー担当者がコードを作成/更新/読み取るときに確認できるリソースを確保します。

6.良いコードを称賛する

コードレビューは必ずしも悪いニュースについてではありません。時々、作者に感謝するようなコードに出くわすことがあります。ロジックの一部、非常に効率的なクエリ最適化、または優れたUX。言ってください。

関連するコードに、nice!好きなことを述べた文章を使って、または長い文章でコメントすることができます。いずれにせよ、その人は感謝されていると感じるでしょう、そしてそれは間違いなくチームワークに違いをもたらします。また、コードの残りの部分がそれほど良くない場合でも、レビュー後にあまり気分が悪くなることはありません。

これらすべてに加えて、作成者は自分が書いた作品が実際に優れていることを検証したので、将来的にそのようなコンテンツを作成したり、他の問題について同様の手順を実行したりできます。

7.謙虚で前向きになる

何年にもわたって、私は読んだthis is stupid、または単にno。悪い日にもそれらのいくつかを書いたかもしれません。

理由等を述べる上記の点は言うまでもなく、そのようなコメントは単に不快で落胆させるものであり、いかなる種類の価値も生み出しません。Gitlabは、さらに読みたい場合にこれに関するいくつかの優れたヒントを提供します。これは、「ポジティブインテント」という会社の価値観と非常に一致しているように聞こえます。

簡単に言えば、レビューのコメントに親切で、相手の時間と仕事を尊重し、コードを書いている間、彼らが最善を尽くしていたと想定することは有益です。コードレビューで自慢したり、屈辱を与えたり、怒ったりすることにはまったくメリットがありません。

以前のコードレビューからコピーした実際の例をいくつか見てみましょう。文の調子を整えている言葉に注意してください。

- shouldn’t this be taking "value" as well 🤔
- maybe you can use "find" instead
- I think start the name with "get..."
- "Synchronize" sounds weird here imho.
- please add an empty line here

私を信じてください、少しimhoまたは「🤔」は大いに役立ちます。

8.リソースを指摘する

私の最初のフロントエンドの日のコードレビューで、cssプロパティの順序付けに関するこのリンクを何回共有したかはわかりません(おそらくstylelintを構成したばかりです🙈)。ある時点でブックマークにもあったと思います。

コードの作成者が問題を解決するのに役立つことがわかっているリソースがある場合は、コメントにリンクしてください。多くの場合、彼らはコメントを高く評価し、それが彼らの仕事で定期的に使用するためのリソースになるかもしれません。このリソースは、大きなリソースがあり、情報を検出するのが難しい場合は、会社のガイドラインの特定のセクションにすることもできます。

おそらく、あなたが指摘できるさらに重要なリソースは、作者が取り組んでいるコードベース内にあります。過去に他の誰かによってすでに実装された同様のロジックまたはコンポーネントは、作成者にとって優れたガイドになる可能性があり、コードベースの特定のセクションを以前に使用したことがない場合は、そのセクションを知らない可能性があります。

改善が必要なコードを検出し、同様の部分が以前に作成されたことがわかっている場合は、作成者がそれを見つけることを知っていると思い込まないでください。コメントでそれを指摘して、作成者が自分のコードを既存のコードと比較したり、改善したり、必要に応じて同じ規則に従うことができるようにします。

9.それはあなたではなく、彼らです

レビューのためにコードを読むときは、それを簡単に理解できることが不可欠です。コードの一部がぎこちないものである場合でも、コードを十分に注意深く読んでいないことに責任があるという意味ではありません。それどころか、それはコードが十分に明確ではないことを意味します。

そのチャンクが何をするのか理解するのに問題がある場合、将来、他の開発者がコードのその部分に触れる必要があるときに、他の開発者をフォローするのは難しいでしょう。そのようなコードを見つけたら、遠慮なく声を上げてください。そして、そのコードチャンクを説明するように作者に依頼するのではなく、代わりに書き直しを依頼してください

本当にもっと明確な方法で書くことができない場合は、少なくとも作者にコードにコメントを追加するように依頼してください。コードの目的を理解するために質問をして、代替アプローチを提案し、解決策について話し合うことができますが、応答に満足するだけでなく、マージされるコードが簡単に理解できるようにする必要があります。

10.あなたはいつも道ではありません

通常、物事を達成する方法は複数あります。コードの一部を読むとき、それを行う他の方法を想像する可能性が高く、それがより良い解決策であるため、コメントでそれを提案する傾向を感じるでしょう。時々あなたは自分自身に尋ねる必要があります:それは本当により良い解決策ですか?それとも、作者のやり方も良いのですが、提案はあなたがいつもやっているやり方に近いですか?

コードの複雑さや可読性に明らかな利点がない限り、書き直しを提案する前によく考えてください。コードを読み直して、チームの規則とコードスタイルに沿っていること、それがうまく機能していることを確認し、それがコードの品質にどのように影響するかを確認するために、考えている別のコードと比較してください。作者のやり方は大丈夫ですが、それでも自分のやり方の方が良いと思う場合は、必須の変更ではなく提案として書いて、提案している変更の理由と詳細について作者と話し合ってください。

これらのヒントが、より効果的なコードレビューアになり、長期的には、コードの作成者、およびチーム全体の時間を節約するのに役立つことを願っています。上記について何か考えがある場合、またはコードをレビューするときに役立つ可能性のあるその他の提案があれば、コメントで知らせてください。 

リンク:https ://betterprogramming.pub/10-tips-to-write-effective-code-reviews-c25c25aa22c5

#code