コードレビューの複雑度を数値化しようとしている

コードレビューをするときに、「これは明らかに一回のコードレビューで見られる量じゃない」という PR が飛んでくることがある。
いい感じに評価できないかと思って、いい感じの計算式を作ってみた。

PR の複雑度を減らしたほうがいい理由

複雑度を減らすには「複雑度」を数値化する必要がある。

あくまで仮採用。

変更する理由の数 = 1 ならば、
(変更行数 * 変更ファイル数 * √(確認箇所 + 1)) < 200

変更する理由の数 > 1 ならば、
(変更行数 * 変更ファイル数 * √(確認箇所 + 1)) ** (変更する理由の数 * (変更する理由の数 - 1)) < 200

変更する理由は 1 つの PR で 1 つにすべき
- 1 つより多いなら、理由ごとに個別の PR に分けるべきなので、累乗の累乗で計算してみた
変更量は多すぎず少なすぎず、仮に 200 行をボーダーとしてみた
とはいえ 10 行の変更を 20 ファイルやられても困るので、確認箇所に応じて補正をかける
- ファイル数が増えればそれだけ確認箇所も増えるはず、という推測に基づく
- リニアではない式にしたほうがよかったかも（放物線とか）
  - ファイル数が少ないときは、それほど複雑度は上がらなそう
影響範囲は PR に関係ないかもしれない
- PR で見るのはコードなので、コードの中で判断できる形式が良さそう
package-lock.json など、計算から除外したほうがいいファイルも存在する

しばらく個人で運用して、この計算式で出した数値と自分の感覚が合っているか確認し、調整していく。

適切な評価ができていると判断したら、ツールにして他の人にも使用してもらう。

最終的には自動化して、複雑すぎる PR は警告を出すといったことができると嬉しい。

これは「コードがどれくらい複雑か」を測る指標なので、コードレビューの複雑度を測るには用途が合わなかった。

コードがシンプルだったとしても、変更が 1,000 行あればコードレビューは辛い。
逆に、変更した関数がいくら複雑でも、typo の修正であればコードレビューの複雑度は低い。