長年にわたってコードの作成とレビューを行ってきた中で、私はより良いプル リクエストを作成し、より効率的にコードをレビューするためのいくつかの秘訣を学びました。 私はこれらすべての秘密を私の新しい本 に注ぎ込みましたが、開発者の活動ですでに使用できるこれらの 13 のヒントを含むプレビューがここにあります。 『プル リクエストとコード レビュー』 もっとヒントを思いつきませんか？コメントで共有してください 😉 1. コードをレビューする準備ができる前に PR を作成します PR ドラフトは、機能の開発中にアイデアを整理し、進捗状況を文書化するのに役立ちます。 2. あなたのPRを見直したくなるようにする 迅速かつ効率的なレビューを得る最善の方法は、PR を小さくし、（必要なすべてのコンテキストを含めて）十分に文書化することです。また、優れたコードを今すぐ提供することで、将来の PR の可能性も高まります。 これらすべてのヒントは、私の無料書籍 で、実際の例や実用的な洞察をさらに詳しく説明しています。 『 Pull Requests and Code Review: Best Practices for Developers, from Junior to Team Lead 』 3. PR の最初のレビュー担当者になる レビュー担当者の立場に立って質問を予想し、役立つと思われる場合は自分のコードにコメントを付けてください。 4. PR に適切なレビュー担当者を割り当てます あなたの PR を全世界に割り当てないでください。承認をあまり長く待たずに、適切なレビューを取得できるよう、レビュー担当者を慎重に選択してください。 5. コメントに応答する フィードバックをオープンに受け入れ、説明を求め、同意できない場合は（敬意を持って）言い、コメントには常に応答してください。 6. 人々にあなたの PR をレビューしてもらいたい場合は、あなたも彼らの PR をレビューする必要があります 誰もがレビューすべき PR をたくさん持っていますが、自由な時間はほとんどありません。他の PR をレビューすると、自分の PR もレビューされる可能性が高くなります。 7. ジュニア開発者でもコードをレビューできます ジュニア開発者は、コードの一部が理解できないときに他の人に知らせることができます。これは、チーム内の開発者なら誰でも理解できるはずです。 詳細については、私の投稿で 。 ジュニア開発者としてコードレビューを行うにはどうすればよいですか? 8. コードレビュー中に正しいことを確認する コードレビューの目的は、バグやエッジケースをチェックし、実装に挑戦することです。これは、小さな書式設定やスタイル設定について細かい点を指摘するために使用したり、大規模なアーキテクチャに関する議論に使用したりするべきではありません。 9. コメントでは適切な口調を使用する 「すべきだ」ではなく「なぜしないのか」を使用し、オープンで前向きな姿勢を保ち、変更を求めるときは常に代替案を提案します。 10. PR を承認するために変更が必要かどうかを明確にしてください すべてのコメントに変更が必要なわけではなく、PR が承認されるために要求されたすべての変更が必要なわけでもありません。変更が緊急でない場合は、コメントで明確にしてください。 11. 送信する前にレビューを確認してください レビューを公開する前に、各コメントを読み直してください。使用しているトーンを確認し、PR 送信者に役立つすべてのコンテキストを提供していることを確認してください。 12. 送信者が要求したすべての変更を行ったら、PR を承認します。 レビュー担当者が、要求したすべての変更を行ってから 2 日後に承認を待つ必要はありません。レビューするときは、すべての修正が完了したらすぐに承認すると想定してください。 13. 一部の競合はコメントでは解決できません コメント スレッドが PR 内で議論になった場合は、それを切り離し、Slack スレッドなどの別の場所で議論を続けることを提案した方がよいでしょう。必要に応じて、そのために専用の会議を開催したり、サードパーティを参加させたりします。 それでおしまい！これらのヒントについてどう思いましたか?他の開発者に伝えたいヒントを 1 つ考えていただけますか? ここにコメントして共有してください 👇 これらのヒントが気に入ってさらに詳しく知りたい場合は、私の著書 を参照してください。無料です。 『プル リクエストとコード レビュー』 でも公開されています。 ここ
