🕌

コードレビューの課題と施策あれこれ

2025/01/31に公開

PR発行時のコードレビューに関して案件運用してきて
感じた課題とその対応など

課題: コードの品質がまちまち

結果レビュアーが何を前提としてみていいかわからないなど、レビュアーの負担が増えます。

対策

基本的には最低ラインを担保することでカバーする対応が主。

コード規約の明文化

命名規則等CIで一律にチェック出来ない範囲の内容が主であると良い。

CIによるリントや静的解析

レビュー前に解消前提で。

PRにチェックリストを作り担保されているものを明示するようにする

GithubのPRテンプレートなどを利用
決め事の内容が荒すぎるとあまり意味がなく、細かすぎるとそれはそれで大変なのが難しい。

課題: レビューがスタックする

自分のタスクを優先しがちという点とレビューに及び腰になるという2つの理由が主。

対策

レビューの優先順位を設定

原則レビューは人のタスクに影響を及ぼすので緊急対応中でない限り、ある程度レビューを優先する必要性を明示。

レビュー工数をあらかじめバッファとして見込む

必死にスケジュールに間に合わせようとしてるときにレビューとかってなりがちなので予めタスクとして見込んでおく。ただそれでも結果自分のタスクに時間を使いたい気持ちは残る問題。

PRのサイズを小さくする

とりあえずウェってならないくらいのPRサイズに。
機能として細分化しづらい場合はmainやdevelop等にマージする前のマージ先を用意しPRのサイズは分割するなど

声掛け

slackなどで直接お願いする。
今日日開発のコミュニケーションはchat駆動が多いので、昔よりはお願いしやすいが、お願いがボットみたいになると効果薄。

レビューされる側が頑張る

  • コード内のコメント(補完的にレビューコメントを自ら書くなどもあり)
  • PRのコメント

PRの時間を計測する

dora 4keysのような開発サイクルを計測する指標を持ちメンバーの認識を合わせる。
gitのサービス毎に対応可能なサービスが異なったり、githubでも外部orgなどで実施しづらかったり等の課題はある。

Slackへの通知

そもそも気付かないがあるのでその対応。
目的は達成されるが通知されまくるので、若干鬱陶しさはある。能動的に気づきにいくならgithub内の通知で頑張るもあるが、習慣づけが必要。

課題: 心理的ハードルがある

前項にも関連するが、参加しづらい、指摘しづらい、依頼しづらいなど。

対策

とりあえず強制してみる

全員必ずやるは敷居が高いので必ずN人承認しないとマージできないなど。(Githubの機能にもある)
ただ、やらない人はやらないし、やるひとはやるということはあった。

コメントにラベルをつける

コメントする方のニュアンスを明示することで申し訳なさの軽減を行う。
下記などを参考にした。
https://zenn.dev/hacobell_dev/articles/code-review-comment-prefix

弱いニュアンスのラベルでも人によっては強制感出るので注意。

ネガティブな書き方を禁止する

禁止というよりは啓蒙かも?
攻撃的な書き方はしない、具体的な改善点を示すなど建設的かつ気持ちの問題みたいな話にならないようにする。

レビューの基準ややらなくてもいいことを示す

物差し、MAX/MINがあることで、ここまでなら出来るよね、これでいいよねを作る。
ただ中央値がMINに偏るとレビューが表面的になりがち。物理的にレビューのしやすさ、レビュー対象のわかりやすさ等も合わせて検討すべき。

まとめ

個人的に大きいなとおもったのはやはり、レビューしやすいPRであるべきという点でした。
そもそものコードの綺麗さやコメントの適切さ、PRサイズもありますが、何をしているかなどを補完してもらえるとレビューしやすいですし、何が担保されているかなどが分かれば見る方の負担も減ります。

株式会社ソニックムーブ

Discussion