中堅に片足入り始めたけど、まだ若手だと思っていたいくらいの人です。

若手じゃなくてもたまにいる「プルリクエストに差分出てるんだからそこ見てよね！」っていう投げやりな人が減ればいいなと思って、自分が気を付けてることと、他の人にもやってほしいことを備忘録。

#説明文に要点をまとめる
大前提の話なんだけど。
色んな要素が関連して、重点的に見てほしい部分は必ずあると思う。
その時に、説明文でもソースコード上でも一言付け足すだけで、レビュアーはまずそこを見てくれる。
言わなければ見られない可能性もある。
レビュアーは人の心が読めるエスパーではないので、言わなければお前の不安な部分なんて知らんってなるから、見てほしい部分は恥ずかしがらずに宣言するのが大切。

#ついでの修正を含めるな
「一覧画面を実装するブランチなのに、削除機能もとりあえず実装しました」
これやる人本当に理解できない。
大体の人がとりあえず実装できないような機能をとりあえず実装してくる。
変更が1ファイルだとしても、機能が違うならプルリクエストは分割するべきである。
新卒の人が「別課題の実装も期限内に実装することが出来たのでレビューお願いします」ってプルリクエスト出して来たら感動する。

#エビデンスをつける
修正内容に対するエビデンスは過剰なくらい添付していいと自分は思っている。
ドキュメントがない現場なら尚更。
エビデンスは相手に納得してもらうものではなくて、自分を守るためと考えると提示する範囲がわかりやすくなる。
自分が意識してやっていることは
・実装前の画面イメージ、バリデーションチェックを課題に記載
・実装する上で前提としている既存仕様の共有
・実装後に実装前の設計と差異が埋まれた部分の記述
・実装したコードの前提とした仕様の記述
このあたりは数行の変更でもやっているし、やるべきだと思っている。
(レビュアーや開発体制でかなり左右されるけど。。。)

レビューしたんだから、お前の責任でしょって言うのもいいけど、それを言う度に信用が落ちて行ってるのをわかってほしい。
穴だらけのものをプルリクエストに出してくる奴はプロジェクトに必要ないと思われる。

#数百、数千のプルリクエストをいきなり出すな
「実装してたらこの差異の行数になりました」
って言う奴、絶対途中でこの行数になるのわかってるだろ。
プルリクエストが肥大化するとわかった瞬間にレビュアーにレビュー単位を確認するべき。
WIPをつけて同じプルリクエスト内でこまめにレビューをしたり、別のプルリクエストにする単位を相談したり、やり方はたくさんあるはず。

これは声を大きくして言いたいけど、
「自分がレビュアーの時にやられて嫌なことはするな」
以上。

#まとめ
他にもたくさんあるけど、適宜追加する。
環境によって違うところが多すぎてなんともいえない部分は多い。
それでも、
「プロジェクトの運用ルールを守る」
＋
「自分の所感を記述する」
これさえやっておけば生きていける。
所感大事。

#雑記
「ローカルでファイルに変更いれてるから、ブランチ切り替えて作業できないです」
って言ってきたおっさん、svnに帰ってくれ。
git stash してくれ。