📌
コード検討者が好きなPR/MRとは？
自分の経験に鑑みてコード検討者が好きなPR/MRを作成するためには何が必要なのか考えてみました。
自分のコードを先に検討する
- 意外と多くの人が自分のコードを先に見直さないまま(PR/MR)を出します。
- Type、コンパイル失敗、分かりづらいコメントなど、、、必ず自らチェックした後、レビューを要請した方が良いです。これはクリーンコードでも指摘されている内容です。
変更内容を明確に記述する
- チェンジログ、コミットメッセージを作成する時に冗長にならないよう、明確と簡潔に書くとより検討者が内容を把握しやすくなります。
コード自体で質問に回答する
- 変更したコードをなぜこういうふうに変更して、そういうふうに修正したのか等について答えする見たいにコメントや注釈をつけたら検討者が内容を把握することにおいて役に立つと思います。
１つのコミットに多すぎる変更は嬉しくない
- １つのコミットに多すぎる変更が入っているとサイドエフェクトが予測しにくくなり、なぜこういうふうに変更したのか検討者が把握しにくくなります。
機能変更と非機能変更を分離する
- 非機能には性能（パフォーマンス）、安定性、保安性、維持補修性など（〇〇性）があります。
- 機能は解決したいその問題（課題）自体です。
- 機能がよくても非機能的にはよくない場合があります。例えば、1+1を計算する機能が性能がよくなくて1時間かかってしまうと結果的には失敗です。
- 機能か非機能か分けることで検討者が検討するポイント・観点も変わるので大事です。
批評に美しく対応する
- 自分が書いたコード自体が自分自身ではありませんので、同一視してしまい敏感に反応・対応するのは良くないです。
検討者が間違えた時にも落ち着く
- 検討者も人間なので時々ミスしたり間違えたりするのを認識して非難するよりは落ち着いて話を続けるほうか良いです。
ある問題について明確にやり取りする
- レビュー中みつけた問題かIssue等について明確にやり取りする必要があります。
- 曖昧な表現を使ってフィードバックをやり取りすると効果的なレビューになりにくくなります。
追加の情報を求める時には賢く質問する
- 例えば、
- 検討者：この関数、分かりにくいですね、
- 答え：何でですか？理解できませんか？(X) -> どの変更をしたらもっと分かりやすくなりますかね？
- 検討者の意見を聞くことが自分が成長するきっかけになるかもしれません。
たまには一応、検討者を信じてみる
- 検討者はふつう自分より経験の豊富な人なので検討者のフィードバックが役に立つかもしれない
- その中で漏れ抜けたことや、思いもしないことが分かるかもしれません。
コードレビューのサイクルは短くする
- レビュー -> 修正 -> レビュー ...このサイクルを短くしないと検討者も自分も何をレビューしていて、何を修正したのか忘れてしまいがちになります。
検討者が把握しやすいPR・MRの作成ができるようになったら、Open SourceのGitにある多くのPRの中で自分が作成したPRが取り上がれる可能性はより高くなるかと思います。
Discussion