こんにちは、jof-fumiです！
この記事は、よりそうアドベントカレンダー 20日目の記事としてお届けします。
自称デグレ発生率が低めの人が普段気をつけていること（開発編） を書いている時、もともとこの記事に開発編とレビュー編を一緒にまとめる予定でした。ですが、あまりにも長くなってしまったため、分割することにしました。
とはいえ、開発編で大体のことを言い切ってしまったので、レビュー編の内容は少し薄めかもしれません。
スタンス
私は常に次のような姿勢でレビュー作業に臨んでいます。
「PRに書いていないことは、やっていないものと思う」
これは、自分がPRを作る時にも意識しているポイントです。
修正内容的にやってなければならない動作確認や調査が書かれていない場合、やっていないと認識しています。
「この動作確認はやっているはずだ」という思い込みは、PR作成者がどれだけ優秀であっても、レビュワーからしたら事実ではなく、単なる想像（もはや妄想）にすぎません。
そのため、基本的にPR内容を疑うスタンスで臨んでいます。これはその人の信用とは無関係であり、疑う基準としてのルールです。
（もちろん、「自動テストのケースを全部PRに記載しろ」というわけではありません。自動テストは大体GitHub ActionsでPR作成時に実行されるようにしているので、実質PRに「書かれていること」とみなしています。）
気をつけていること
1. 影響範囲の広い機能が修正されていた場合、pullしてGREP調査をする
共通コンポーネントや他のファイルから呼び出される関数など、影響範囲が広そうな場合は、自分のローカル環境にPRをpullしてGREP調査を行います。
時間がない時は「GREP調査しましたか？」というコメントを残すだけにすることもありますが、基本的には自分で調査するようにしています。
結構めんどくさいのですが、これをすることで拾えた修正漏れなどが、どの現場でも幾度となくあるので、基本的にやって損はない作業だなと思っています。
ちなみに、自分が作業者の時は、逆に「GREPしました？」と聞かれたくないので、調査内容や自動テスト外の自分で打鍵したテストを網羅的に書くようにしています。
ちょうど、スタンスに書いたことと表裏一体の関係性になってます。
（自動テストを導入推進して、これを全くやらなくていいようになりたい！）
2. 結合度の高い実装を許容しない
結合度の高い実装を許容すると、以下の問題が発生します。
- 影響範囲が広がり、デグレが発生しやすくなる。
- 既存コンポーネントの使用方法が崩れ、今後の修正でもデグレの可能性が高まる。
このため、結合度が高い実装は可能な限り許容しないようにしています。
結構当たり前かな〜と思いつつ、作業者が他のレビュワーとそれなりに指摘対応をしたあとに気づいたりしたら、ちょっと言いづらいですよね…。
でも妥協はせず、指摘するようにしています。
3. ファイル数の多くなるようなPRは、作業を分割して小さいPRにしてもらう
これは開発編でも触れたポイントですが、レビューでも同様です。
できる限り作業を分割し、小さな単位でPRを作成してもらうようにしています。
とはいえ、「作り直せ」と強要するのではなく、「次回からそうしてね〜」といった柔らかな対応を心がけています。
結局、ファイル数が多いPRは次のような問題を抱えていると考えています。
- 修正対象の理解が不十分: 修正対象の仕様や挙動、ロジックを適切に理解していれば、影響範囲を小さくする作業分割が可能
- 設計の考慮が不十分: 修正対象を理解してもできない場合は、コンポーネント間の結合度が高いと考えられるので、設計の見直しが必要
また、シンプルに修正箇所が多いと見落としが発生しやすくなり、レビュワーの負担増加 にもつながります。
AIの活用
これに加えてAIの活用も行っています。
https://qiita.com/punkshiraishi/items/629753be2e4d08fd1f42
よりそうではAIの活用を積極的に推進しており、今季はCursorというAIエディタの導入が実現しました。有料プランを契約してもらったおかげで、開発スピードが飛躍的に向上したメンバーもいます。
良い会社ですね〜。
最後に
デグレを防ぐ取り組みは、個々の開発者だけでなくチーム全体の責任です。
今回紹介したレビュー時に気をつけているポイントは、私が実際に実践している、どちらかといえばマインドに近い部分です。
もちろん、チームとして仕組み化を進め、自動的にバグを減らす取り組みも実践しています。
ただし、個人のマインドセットがないと、仕組みの必要性に気付けなかったり、スピード重視で修正漏れが発生したりすることもあります。
そのため、チーム全体でマインド面を成熟させながら、安心してリリースできる開発チームを目指していきたいと思います。
最後まで読んでいただき、ありがとうございました！