誰かと開発することを忘れかけていて、
もぅﾏﾁﾞ無理。。。とりあえずLGTMしょ。。。
となりかけてしまったので、尊敬できるエンジニアである夫に相談してみました。
世の中の正解かは分からないですが、私は参考にしたいと思ったのでまとめます。
レビューの仕方がわからないです！！どこから見たらいいかわからないです！！
プルリクでは「意図」がわかるようにしたほうがいい。
夫が所属しているチームでは下記の内容をプルリクの説明(description)に書いているそうです。
バグだったらどういう問題があったか、機能だったらこれを入れたら何が改善されるのか(なにが嬉しいの？)
変更概要
変更概要を読むとdiffを見たときに意味がわかるように
こういう理由でこういう実装になっている、こういう理由でここは直さなくてもいい、などを書く
関連Issue
チケット(issue)へのリンク
影響範囲(テストすべき範囲)
どこに影響が出るか
この認識が実装者とレビュアでずれてたらおかしい
テスターがいる場合はテストすべき範囲がわかる
メモ(実装時に気になったことなど)
調べたもののリンク、ビミョーだけど今こうするしかないから今後こうしたいねという想い、なんでも
※上記を書いていたらプルリクが分かれるはず、とのことでした。
ちなみにプルリクのテンプレートというものがあるらしくGitHubでも設定できるそうです。
GitHubのIssue・Pull Requestのテンプレート機能を使おう - Qiita
「密にコミュニケーションとれるんだからそこまでしなくてもいいんじゃない」って言われたらどうすれば…？
次に入ってくる人はそれで困らないの？
まとまってない段階でコミュニケーションして、あなた( @maetoo11 )は困らないの？
→これは確かにそうで、私にとっては会話やチャットで聞き出すのは高コスト(MPの消費が激しい)ということを思い出しました。
「速さが大事だからそこまでしたくないんだよね」って言われたらどうすれば…？
そこまでしないならレビューしなくていいと思う
“そこまでしない"状態でレビューするのはやった気になってるだけ
→ううううううう(´-﹏-`；) 100%は無理でも意味のあるレビューできるようになりたいです…！
コミットの粒度は雑でもいいの？
そもそもこれを満たしたら(上記のプルリク説明を書くようにしたら)プルリクごとに読めるはず。(コミットは気にしなくてよくなるはず)
→これは場合によるかな、と私は思います。コミットごとにロールバックすることとかあるかもしれないですし。
粒度に関しては私は下記記事が参考になります。
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
感想
夫と話して気づいたのですが、なぜここまで悩んだかというと
『意味のあるコードレビューがしたい』
と思ったからでした。
『JetBrainsのIDEはコードを書くということに集中できるようにつくられている。
それと同じようにプルリクの説明をきちんと書いたり、コミット粒度を考えたりするコストをかけてもレビューすることに集中できたほうがいい』
と思いました。
