チームで作業するとコードレビューをする文化が多くなっていると思います。
実際にコードレビューを最近までしてなかったので、アンチパターンや良い仕組みがどういうものか考えたことがありませんでした。
機能ごとにプルリクエスト（PR）を作成していたプロジェクトに参加していましたが、色々と経験できました。
サイズ（ライン数）
機能ごとにPRを作成するため、PRごとに規模がかなり違いました。
簡単な機能であればいいですが、画面とモデルが関係している場合、2000行以上になるものがありました。viewが大半にはなりますが、controllerやロジックの確認も時間がかかります。機能自体複雑な場合もあるので、機能ごとだとライン数が多くなる印象です。
どのくらいが適切かわからないですが、500行ぐらいに収まるとありがたいですね。
頻度
機能ごとだったため、ひとりが1週間に1回PRを作成するぐらいな頻度でした。機能や進捗により2週間に1回の人もいた感じです。
コードレビューも回数は少ないですが、スケジュール的に試験に入る前に期限の場合が多く、一気にくるパターンもありました。
できるだけ自分の作業を早めに終わらせていたため、コードレビューがあってもなんとかできていました。
試したこと
コードレビューを何回か行い、どういうコードレビューが良いのか考えるようになりました。本やブログ記事でも気になるようになり、ちゃんと読むようになりました。
すでに世の中では、同じ道をたどった人が多くいるおかげで、参考にできることが多かったです。
まず「分割」することを試しました。
分割
機能ごとだったり1週間に1回だったところを分割してPRを作成することを試してみました。
分割の単位については検討しましたが、1日単位の規模でキリがいいところでPRを作成してもらいました。関数単位とか100行とかの案もありましたが、レビュー回数が増えることを懸念して1日単位にしました。
個人的にはかなり良い結果を得られたと思います。
- 進捗把握
- 1回あたりのレビューのライン数の減少
- 問題点の早期発見
フルリモートでの仕事の影響もあると思いますが、進捗把握が難しい人が多い印象でした。難しそうな部分がない機能でも想定より時間がかかってそうな場合でも、「期限内にはできそうです。」と報告されれば任せてしまいます。ちゃんと遅れていることを報告してくれる人は稀だと思います。
そんな中で進捗が把握できることは個人的にはありがたかったです。「ここまでできているなら、期限内に大丈夫そう」という安心が得られることはレビュー回数が増えても良い結果だと思いました。
また機能自体の把握もコードが分割されているため、したいことが把握できたことも良かったですね。
まぁ、一定期間試してから機能ごとに戻りました。これはお試しで行ったこともありますが、メンバー変更による試作の継続につながらなかったため自然に戻ってしまいました。
アンチパターン
試したこととは別ですが、あまりよくない仕組みも経験したと思います。
- だれかがレビューをすればいい -> 誰もしない
- 期限を決めない -> いつまでもレビューされない
- コードの整形 -> ツールで指摘したほうがいい
経験しないとわからない
車輪の再発明という言葉はありますが、経験しないとわからないことは多いです。
失敗しないと考える機会につながらないし、「なぜ」がわからない人は言われたことしかできない人が多い印象です。
失敗をすることができる環境は良い環境だと思います。試行錯誤は重要ですね。
