マージリクエストの書き方について
-
2023年12月26日
こんにちは、ポケコロツインプロジェクトでクライアントエンジニアをやっているKです
早速ですが、みなさんはコードレビューをやっていてモヤっとしたことはないでしょうか？
例えば、人によってプルリクエスト（マージリクエスト）の書き方や大きさが違って、「何をやりたいかわからないけど、なんか問題なさそうだから、ヨシ！」となってしまった記憶など・・・
今回はその問題を解決するための取り組みとして私たちのプロダクトで行った、マージリクエスト（以降MR）の記載内容のルール化について書かせていただこうと思います！
私たちのプロダクトではMRのテンプレートを使って、被レビュー者がレビュー前に記載する内容のルールを作っています。
まずは最初にお見せした方がイメージしやすいと思うので、以下に実際に使用しているテンプレートの一部を掲載させていただきます。
# 目的
*こちらに改修の仕様、バグのチケット、相談内容や背景を記載してください*
# 変更内容
*こちらに変更の概要を記載してください（○○の画面のUIを更新や、○○の機能で××ができるようにしたなど）*
変更内容サンプル
# ローカルテスト
*こちらに行ったローカルテストの内容を記載してください*
- [ ] チェック項目サンプル
# 特にみて欲しいところ
*レビュー者に特に気をつけて確認して欲しい箇所があれば記載してください*
# 懸念事項
*変更による懸念事項（他箇所への影響や、確認できなかったことなど、相談したいこと）があれば記載してください*
# その他の伝達事項
*その他伝えたいことがあれば記載してください*
いかがでしょうか？「書く項目が多くて面倒だなぁ・・・」と思った方もいらっしゃると思うので、この中でも重視している項目の意図についてお伝えしていこうと思います。
「目的」
レビュー者は、被レビュー者の現在やっている施策の開発状況や、差し込み対応などがあった場合、やろうとしていることの背景を知らないこともあるかと思います。
その状態でレビューをしてしまうと、実はそもそも実装方針に問題があるとか、実は変更をしないと決めた別の理由があったりとか、コードの変更以前の問題に気付けないかもしれません。
そういった問題を防ぐために、開発している施策があればその仕様書や、その中でもどんなことをその実装で達成したいかを記載したり、差し込み対応であればどんな問題があってその改修を行おうとしたかなど、改修や開発を行う背景や目的を記載するようにしています。
「変更内容」
MRの中に複数の機能変更や開発があった場合、それらの変更と変更の影響を受ける箇所が混在してしまい、レビュー者はそれらの関連を読み解くことから始まり、レビューの難易度や大変さが上がります。
そして読み解く難易度や大変さが上がれば上がるほど、レビューの精度は落ちてしまいます。
それを少しでも軽減するために改修・開発した機能の概要を記載することで、コード変更の全容を掴みやすくし、レビューをしやすくすることを心がけています。
「ローカルテスト」
エンジニアの実装は実装だけでは終わりません。自らの実装内容を確認し、品質を極力上げることも重要です。
そのため、ローカルテストを実施した項目をしっかり洗い出し、確認した内容を記載するようにしています。
レビュー者としても、どんなテストをしているかを確認し、被レビュー者が認識していない影響範囲や、関連したテストを指摘することができます。
このように被レビュー者がレビュー者にレビューして欲しい内容をしっかり伝えることで、レビューをしやすくし、かつ精度を上げることができます。
プロダクトによってはリーダーなど、特定の人がレビューを行っているかもしれませんが、レビューの難易度を下げることで、若手メンバーもコードレビューができるようになり、特定のレビュー者の負担を軽減し、若手メンバーの成長機会を増やすことにも繋がります。
やってみてどうだったか
私たちのプロダクトではこのMRのルールに変えて、かれこれ1年ほど経っていますが、相互レビューの文化は活発で、コメントでの議論も活発にされています。（MRのルールのおかげだけではないですが）
また、この形式にしたMRの量もそれなりに増えてきており、過去の実装の理由や背景を知りたい時の資料としても大いに役立っています。
新たにプロダクトに参加される方からも「分かりやすくて良い」と好評です。
レビューまでにかかる手間は増えましたが、得られる恩恵はそれ以上に大きいかなと思っています。
エンジニアとして制作物の品質を高めるためにコードレビューはもちろん重要ですが、コードレビューを容易にして、レビューそのものの質や精度を高めることも重要だと思います。
チームによって適切な形は違うため、今回紹介した方法がそのまま参考にならないこともあるとは思いますが、コードレビューのやり方を改善するきっかけになればと思います。
