SideCI Blog

自動コードレビューサービスSideCIを提供している株式会社アクトキャットのコーポレートブログです。



コードレビューの自動化を考えるべきタイミング

コードレビューの文化は開発者の中で浸透してきています。多くの組織では開発メンバーが全員集まって特定のメンバーのコードをチェックしたり、プルリクエストに入っているコードをチェックしたりするのではないでしょうか。

他のメンバーからの指摘は時にためになりますし、新しい書き方を学ぶ機会にもなります。しかし徐々にメリットよりも負担のが大きくなっていくことでしょう。もし以下に挙げるような事柄が該当するのであれば、それは自動化を考えるべきタイミングです。

プルリクエストが日に10件を越える

基本的にコードレビューはプルリクエストごとに行われるべきです。コードレビューを経ることで自社のコーディングスタンダードに合っていないコードが入り込むのを防げるようになります。しかしプルリクエストが日に数件ならばともかく、日に10件を越えるようになると負荷が大きくなります。

10件というのはあくまでも目安ですが、1件のチェックに平均10分を費やしていたとしたら10件で100分になってしまいます。コードレビューの責任者の多くは開発のリードエンジニアになるので、その人の高い生産性がコードレビューによって奪われてしまうのは非常に勿体ないでしょう(もちろん最初は教育目的も兼ねて行われることも多いです)。

開発人数が3人を越える

コミュニケーションのパスが増えれば増えるほど一つの作業に対するコストが増大します。人力でのコードレビューが開発者が集まるミーティングの中で行われたりすると、まとまらない議論が延々と続いたりします。

SideCIを導入されているチームの規模は数人から数十人と様々です。最適な人数というのはありませんが、開発者が増えていくタイミングこそコードレビューの自動化を考えるべきときです。

コードレビューの品質を考え始めるとき

人が定性的に行うコードレビューでは一定の品質を保つのが難しいでしょう。その場の思いつきであったり、人によって綺麗なコードのあり方は変わってきます。そこで誰しもが考えるのがコードレビューのルール化であり、標準化です。

ルールや標準を定めようと考えるタイミングこそ、コードレビューの自動化を行うべきときです。ルールを設けると言うことは、それをプログラマブルにすることで自動化できるようになります。ルールの定期的なアップデートは可能ですが、適用している限りは同じ条件に沿ってコードを見直してくれます。その結果、同じ品質を保てるようになります。

レビュアーの生産性を脅かしはじめたとき

コードレビューはとても大切な開発プロセスですが、レビュアーの負荷は決して小さくありません。最初こそアラが幾つも見つかるものの、徐々に品質が上がってくると問題視すべき点も減ってきます。かといって気を抜くと徐々にコードの品質が悪化します。

コードレビュアーの負担としては、改善プロセスよりも維持プロセスのが大きいかも知れません。品質の維持プロセスに入ったと判断できたとき、自動化することで品質の維持とレビュアーの負荷を軽減できるはずです。


コードレビューはとても大事なプロセスですが、その負荷の高さから導入を躊躇してしまったり、途中で止めてしまうチームも多いはずです。だからこそコードレビューの自動化をお勧めします。

SideCIではESLintを用いたNode.jsプロジェクトのコードレビューに対応しています。コードを綺麗にすることはコードの品質を高め、ひいてはチームの生産性を向上します。ぜひお試しください。