[Tips]プルリクエストの悩みと対処法を考えたい
1.はじめに
サービス開発本部プロダクト開発部フロント開発グループの赤松です。
フロントエンドエンジニアとして、「au PAY マーケット」の開発を実施しています。
新卒3年目となりプルリクエストのレビュイー・レビュアーを実施する中で感じた課題感を棚卸し、今後に活かすこと・心掛けていることについて、この記事では、まとめていきます。
2.プルリクエストの悩み
弊社では、GitHubを利用してコードレビューを実施していますが
その際に下記のような悩みを感じることがありました。
レビュイー（プルリクエストを作成する側）の悩み
・コードに対して指摘されることが怖い
・プルリクエストの内容記載が面倒
・マージまで1週間以上かかる
レビュアー（レビューする側）の悩み
・何をレビューしたらいいのか分からない
・approvedが承認になっている
・細かい指摘をするかどうか迷う
上記の課題感ですが、もしかすると心当たりがある人も多いのではないでしょうか？
これらの課題は「マインドセットを変える」「伝え方に工夫をする」「自動化する」などで解決できるものだと考えています。上記に対して弊社＆私が考える原因と実践している内容をまとめていきます。
3.レビュイーの課題と対処法
レビュイー時に感じていた課題と対処法についてまとめました。
コードに対して指摘されることが怖い
正直、私もコードを見てもらうことに少し恐怖心はあります。
特に技術に対する自信が少ない場合、レビューをもらうことで考慮不足が可視化されるため力不足を実感し、コードに対する指摘が自分自身に対する指摘と感じてしまいます。
本来、プルリクエストは対等な関係で実施し、より良いプロダクトを作成するための工程ですが、少しの意識の違いで問題が発生しているのでしょう。
せっかく個人の知識レベルを向上できる工程なのに勿体無い…
対処法
なぜプルリクエストが必要なのかレビュアーと認識合わせする。
→レビュアーとなぜプルリクエストが必要なのか納得するまで話し合いましょう。ほとんどの場合、攻撃しようとしてレビューをしている人がいないことに気づくはずです。
アドバイスを早く貰ったほうが手戻りが少ないと考える
→レビューを早い段階でもらうことで手戻りを防ぐことができます。また手戻りを防ぐことで早くプロダクトを提供できるようになります。
そもそも有識者とペアプロしながら実装する
→設計〜実装工程で有識者に依頼しペアプログラミングをしましょう。利点として「レビューするより前に手戻りを防ぐ」、「実装とレビューを兼ねる」ことが可能です。
最初は見られながらコーディングすることに抵抗感があると思いますが、ペアプロのベストプラクティスに則り作業するとその抵抗感が少なくなると思います。
ペアプロの具体的なプラクティスについては、詳しく解説されているものもあるのでぜひ調べてみてください！
プルリクエストの内容記載が面倒
レビューしやすいプルリクエストを作成するためには、多くの情報を記載する必要があり時間を多く費やします。
コーディングまではやる気が出るが、プルリクエストの中身を作成することは面倒くさい人は私だけでしょうか？
また、誰がレビューをするのかも非常に重要な情報となります。要件定義を理解している人がレビューをすれば、記載内容は少なくても早くレビューが終わります。レビュアーが誰なのかも重要なポイントでしょう。
対処法
フォーマットを作成して指定する。
→まずはリポジトリにフォーマットを指定しましょう。そうすればプルリクエストが作成された際にそのフォーマットが自動的に反映されます。
▼詳しくはこちら
マージまで1週間以上かかる
軽い修正プルリクエストを作成し、レビュー依頼したが誰にも確認されず、時間をおいてリマインドするも1週間以上経過している。
その間タスクは進まないので進捗が非常に悪い。
もちろん相手が忙しいというのも原因の一つだと思いますが、こちらにも問題点がある可能性があります。意外にレビュアーが1から理解するのが面倒くさく放置されている可能性もあります。
対処法
プルリクエストの粒度を狭くする
→もし更新ファイル数が20件以上ある場合、プルリクエストが巨大すぎる可能性があります。レビュアーの立場になってその数のファイルを確認すると思うと気が重くありませんか？
1プルリクエストに1つのテーマで実装するようにしましょう。
レビューしてもらいたい部分を明瞭に記載する
→あなたがレビューで確認して欲しい観点はなんですか？
致命的なバグを事前に見つけて欲しい
コードの品質を保ち技術負債を防止したい
事前に手戻りを防ぎたい
実装中に迷いながら採用したコードへの質問
コードを読む中で隠された問題点を探すには労力が必要です。できるだけレビュアーに伝えるようにしましょう
▼GitHubの公式ブログが非常に参考になりおすすめです。
4.レビュアーの課題と対処法
レビュアー時に感じていた課題と対処法についてまとめました。
何をレビューすればいいか分からない
レビュー依頼のConversation(会話)の記載が少なく、「原因が何なのか」「どのような実装を加えたのか」「どのような部分にこだわりを持っているのか」読み取るのに時間を要します。その結果当たり障りないレビュー、あるいは、レビュー対応を先延ばしにしてしまうでしょう。
対処法
フォーマットを作成して指定する。
→レビュイーの対処法と同様にフォーマットが指定できていれば最低限の詳細は担保できるでしょう。
レビュイーと対面でレビューを実施して実際の動作を確認する
→また緊急でレビューが必要な場合はミーティングで対面対応するとすぐ完了する場合があります。あくまでプルリクエストは良いプロダクトを作成することが目的なので、テキストベース以外の対応方法を取り入れてみるのも一案です。
▼VSCodeを利用している場合は下記拡張もおすすめです。
approvedが承認になっている
弊社のフロントチームではプルリクエストに対して2つのapprovedをすることでマージできるようにルール設定しています。
本来、複数人でレビューすることで品質を高めるという目的があったはずなのにマージを優先するためになんとなく大枠だけ確認してapprovedしてしまうことはありませんか？
もしかすると、approvedが実装責任を負うための承認になっていて健全なレビューになっていないかもしれません。バグが発生した場合、承認者・開発者が責任を求められるなんて嫌ですよね？
対処法
もし障害が発生してしまったら腹を括ってチームでリカバリをする
→障害が発生した場合、実装者ではなくチームで対応できるようにレビューをして要件理解を計りましょう。
あくまでapprovedは承認作業ではなく、プロダクトの品質を高める工程であり、『LGTM』です。責任をチームに分散しましょう。
LGTM (Looks Good To Me - 良さそうだね)
細かい指摘をするかどうか迷う
細かい命名・メソッドの位置・パスの指定・ファイル末尾の改行などあまり影響はないが統一したい指摘や個人的なポリシーを持つエンジニアは少なくないと思います。
細かすぎる指摘をすると迷惑かと思い、あえて指摘しない。スケジュールがギリギリなのを分かっているのであえて指摘をしない。そのような場合だとコードの可読性が悪くなります。
対処法
人間が確認する範囲をできるだけ減らす
→できるだけ楽できるようにツールを導入しましょう。下記はフロントエンドで代表的に利用されるツールです。
ESLint
Prettier
stylelint
ツールを使い、コード規約を指定することで人間の確認する観点を減らしつつ、コードの品質も向上します！
人間はより重要な部分をレビューしましょう！
5.要点まとめ
私なりのプルリクエストを実施する意味を記載します。
・チームでコードの品質を高める
・コーディングに対する議論をすることで仕様理解・技術力を向上させる
ぜひあなたが考える「プルリクエストを実施する意味」を教えてください！
6.終わりに
新卒から3年間の中で体験したプルリクエストの悩みと対処法をいくつか書かせていただきましたが、所属するチームによって状況が違う場合もあると思います。その場合でも認識を合わせて建設的な議論をすることでレビュースピードも向上し、開発効率もグッとあがることでしょう！
あくまでプルリクエストはコードを見てもらう工程なだけなので、効率的に進める方法があるなら対面でも録画・ホワイトボードでもなんでも利用しましょう！！
この記事がみなさんの悩みを解消する手助けになれば嬉しいです。
それではみなさん良いエンジニアライフを！