レビュワーに不親切なコミットの条件を理解する

前提

コードレビューの修正が一つにまとまった「レビュー対応」という名のコミットを見たことがある方は多いのではないでしょうか。
また、機能追加（feat）なのか、修正（fix）なのかでコミットの粒度が変わってしまう人もよく見かけます。

これは特にレビュワー経験の少ない初級エンジニアにありがちで、レビュワーに不親切なコミットの条件を理解できていないことが原因だと思います。

どのように解決するか

上記の例では、どの差分がどの修正に対応するものなのかわかりづらいという問題がありますが、一度レビュワーを経験することで、アンチパターンから避けるべき行動を学習することができます。

FLATでは入社後初期からコードレビューを経験してもらうために、相互レビューという制度を設けています。
ポジションやスキルに限らず、プロジェクトメンバー同士で相互にコードレビューをしてもらうことで、チーム全体でコミットやプルリクの粒度に配慮する習慣が身に付いています。

コミットの粒度はレビュー効率に大きな影響を与えます。レビュワーの経験が少ない方はぜひ積極的に手を挙げてみると良いでしょう。