前書き
フロントエンドエンジニアとして、通常はチーム内で最も多くのプルリクエストを送信する人です。自分のプルリクエストがテストしやすく、レビュアーが簡単にレビューできるようにするために、いくつかの注意点をまとめました。
プルリクエストの説明
- このプルリクエストの目的。例：レイアウト修正、新機能追加、特定の画面のスタイルなど
- 会社のメンバー全員がプルリクエストを見ることができることを念頭に置いて、プルリクエストの説明に十分な情報を提供してください。
- フィードバックをどのように希望するかを明確に説明してください。
- プルリクエストの状態を説明するためにプレフィックスを使用してください。
- このコードを見る必要があるメンバーを追加してください（GitHubのアサイン機能を使用できます）。
フィードバックの提供
- プルリクエスト内のコーディングスタイルに同意しない場合、なぜ同意しないのかを考えてからコメントを残してください。
- 命令ではなく問い合わせを使用してください。「なぜこの方法を採用しないのですか？」は「このように書かないでください」とより優れています。まず相手の意見や考えを尋ねてみてください。彼らがその方法を選んだ理由があるかもしれませんので、適切なコミュニケーションと意見交換ができます。
- なぜそのコードを修正する必要があると思うのかを説明してください（スタイルガイドに準拠していない？会社の命名規則に準拠していない？テストケースが書かれていない？）。
- 現在のコードを改善するためのより良い方法を提案してください。
- 攻撃的なコメントは避けてください（例：この書き方は愚かです）。
- 謙虚でいてください。
- 断定的な発言は避けてください（このようにコードを書かないでください！）。
- オンラインでのコミュニケーションでは、誤解が生じることがあります。その場合は直接会って話すことを検討してください。
- 絵文字を使って表現を強調してください。例：good job 👋 👍。修正が必要です👻（これは少し皮肉かもしれませんね？）
フィードバックへの応答
- コードレビューを手伝ってくれる人々に感謝してください。
- 疑問がある場合は質問してください。
- そのフィードバックが実装されているか、またはどのコミットにあるかをリンクで提供してください。
- 議論がますます複雑になり、結論が出ない場合は、直接話し合ってみてください。
すべての人に対して
- 皆が異なるコーディングスタイルを持っていることを理解する必要があります。また、プログラムを書く際には多くの解決策や選択肢があるため、議論する際には適切なバランスを取り、なぜそれがより良いと考えるのかを十分に説明する必要があります。
- 命令ではなく問い合わせを使用してください。
- 責任を分けないでください（これはあなたが書いたもので私には関係ない、この部分はあなたが対処する必要がある）
- 著者の視点や考えを理解しようとしてください。
結論
上記は多くのポイントをまとめましたが、重要なのは相手のことを考えることです。どのようなプルリクエストを見たいかを考えて、その視点からアプローチすると、感銘を受けるかもしれません。 何しろ、自分のミスによってコードを本番環境にデプロイしてしまい、チーム全体の時間を無駄にしてバグを探し、再度デプロイすることになるかもしれませんので。
