プルリクとかレビューについて尊敬できるエンジニアに相談してみた話

誰かと開発することを忘れかけていて、
もぅマヂ無理。。。とりあえずLGTMしょ。。。
となりかけてしまったので、尊敬できるエンジニアである夫に相談してみました。

世の中の正解かは分からないですが、私は参考にしたいと思ったのでまとめます。

レビューの仕方がわからないです!!どこから見たらいいかわからないです!!

プルリクでは「意図」がわかるようにしたほうがいい。

夫が所属しているチームでは下記の内容をプルリクの説明(description)に書いているそうです。

なぜこの変更を入れるのか
バグだったらどういう問題があったか、機能だったらこれを入れたら何が改善されるのか(なにが嬉しいの?)

変更概要
変更概要を読むとdiffを見たときに意味がわかるように
こういう理由でこういう実装になっている、こういう理由でここは直さなくてもいい、などを書く

関連Issue
チケット(issue)へのリンク

影響範囲(テストすべき範囲)
どこに影響が出るか
この認識が実装者とレビュアでずれてたらおかしい
テスターがいる場合はテストすべき範囲がわかる

メモ(実装時に気になったことなど)
調べたもののリンク、ビミョーだけど今こうするしかないから今後こうしたいねという想い、なんでも

※上記を書いていたらプルリクが分かれるはず、とのことでした。

ちなみにプルリクのテンプレートというものがあるらしくGitHubでも設定できるそうです。
GitHubのIssue・Pull Requestのテンプレート機能を使おう - Qiita

「密にコミュニケーションとれるんだからそこまでしなくてもいいんじゃない」って言われたらどうすれば…?

次に入ってくる人はそれで困らないの?
まとまってない段階でコミュニケーションして、あなた( @maetoo11 )は困らないの?
→これは確かにそうで、私にとっては会話やチャットで聞き出すのは高コスト(MPの消費が激しい)ということを思い出しました。

「速さが大事だからそこまでしたくないんだよね」って言われたらどうすれば…?

そこまでしないならレビューしなくていいと思う
“そこまでしない"状態でレビューするのはやった気になってるだけ
→ううううううう(´-﹏-`;) 100%は無理でも意味のあるレビューできるようになりたいです…!

コミットの粒度は雑でもいいの?

そもそもこれを満たしたら(上記のプルリク説明を書くようにしたら)プルリクごとに読めるはず。(コミットは気にしなくてよくなるはず)
→これは場合によるかな、と私は思います。コミットごとにロールバックすることとかあるかもしれないですし。
粒度に関しては私は下記記事が参考になります。
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita

感想

夫と話して気づいたのですが、なぜここまで悩んだかというと
『意味のあるコードレビューがしたい』
と思ったからでした。

『JetBrainsのIDEはコードを書くということに集中できるようにつくられている。 それと同じようにプルリクの説明をきちんと書いたり、コミット粒度を考えたりするコストをかけてもレビューすることに集中できたほうがいい』
と思いました。