この記事を読めば何ができるようになるのか
- 見やすいPRの書き方がわかります
- レビュワーが見やすいレビューを書くための心得がわかります
対象読者
- よりよりPRの書き方を知りたい
- レビュワーからわかりにくいと言われたことがある
PRの書き方
ここでは、是非PRに書いて欲しいこと、使って欲しい表記方法について紹介します！
またこれから
レビュアー : レビューする側(依頼されたPRをレビューする人)
レビューイ : レビューされる側
とします
今の現状を言語化して記載しよう！
変更前の状態を言語化しましょう。デザイン変更や新規画面作成ならスクショもあると、よりわかりやすいです。
これをすることで、コードを見る前にレビュアーは変更前の大体の概要を予想できます。
変更理由/作成理由を記載しよう！
レビュアーは、今回の変更/作成の理由を全部知っているわけではないです！(もちろん知っている場合もあるでしょう)
これがない時、レビュアーは「このコードはなんのために変更/作成されたんだ？？」となってしまい、レビューの際に、「コードの整合性、綺麗さ、エラー確認、挙動確認」等しか判断できません。
「別にそれでよくない」ったかも知れません。
ここで例を見てみましょう！
ex) Buttonコンポーネントを作成したPR
interface ButtonProps {
onClick?: () => void;
title: string;
}
const Button: React.FC<ButtonProps> = ({onClick,title}) => {
return (
<button type="button" onClick={onClick}>{title}</button>
);
};
export default Button;
作成理由を書いていない場合、レビュワーはおそらくlgtmを出すでしょう(コード的に問題はないと判断して)
では、ここに作成理由として以下があった場合、どうなるでしょう？
「今後form等でも使うので、components化した」
こうなった場合、話は変わってきます。
レビュワーはchanged requestを出して、
「typeをpropsで渡せるようにした方がよさそうですね〜」
とするでしょう。
もし、変更/作成理由を書いていなかったら、form内でこのcomponentsを使うとなったときに修正PRを作成する必要が出たでしょう。少なくとも手戻りが発生します。
変更理由を書くことは、レビュワーだけでなく、レビューイにもメリットがあります！
ただ画像を貼り付けない！
作成した画面、修正した画面、apiからのレスポンスの中身...
これらをただスクショして貼り付けるだけになっていませんか？？？
確かに、証拠として収めているからいい。そうです、貼っているだけでも十分レビュワーのことを考えられていると思います。
(スクショすら貼ってない人は、貼りましょう。しっかり自分の環境では動いているよ〜、の証明になるので)
tableをつかって見やすくしてあげましょう！
「わざわざつくるのめんどくさい」 「毎回tableの作り方調べて、コピペするのだるい」
なんて思ってませんか？、それgithubが提供してくれているんです。
/ (半角スラッシュ)を打つと、選択肢が出てくるので、そこからtableを選択してあげれば終わりです。
あとは自分が作りたいtableの形を選択してあげるだけ。
めちゃくちゃ簡単でしょ笑
最後にtableを使っている例と使っていない例を比較して(どっちの方が見やすいでしょうか？比較しやすいでしょうか？)
例
| tableなし | tableあり |
|---|---|
 |
 |
まとめ
以下の２点を行なって見てください
- 変更/作成理由を記載する
- tableを使って、見やすくしてみる
最初はめんどくさいと思うことでしょう笑。時間かかるし別にやらなくても良くない？って思うかもしれません。
しかし、これらのちょっとした気遣い、配慮が、後々の手戻りや勘違い、認識の齟齬を減らす行為に繋がってます(と自分は信じてます。)
是非是非実践して見てください！！！
最後に
ちょっと自分について
都内大学３年生(26卒)。大学に入って、もともと興味のあったプログラミングをプログラミングコミュニティPosseに入って勉強。コミュニティ内のハッカソンやチーム開発を行ってきた。去年から長期インターンを行なっている。
どうして書こうと思ったのか
長期インターンを通して、メンターさんにレビューされにくいPR、されやすいPRがあることに気づきました。最初は
変更箇所が多い→見るのに時間かかるからレビューされにくい。
変更箇所が少ない→見るのに時間かからないのでレビューされやすい。
だと思っていた。
確かにそれもあるのだが、自分がチーム開発等で レビューする側になった時、レビューしやすいPR,レビューしにくいPRがあることに気づいた
レビューしてもらうPRを書いてもらうために、そしてメンターさんにレビューしてもらえる、気持ちよくレビューできるためのPRを書けるようになるための方法をまとめて忘れないようにしたかったので、この記事を書くことにしました。
参考になれば幸いです...
(間違っていることもたくさんあると思います。すぐ修正したいので連絡お待ちしてます🙇♀️)