AIが書いたコードの量が増えると、一件ずつ読むのが追いつかなくなります。全部は読めませんが、全部を同じ物差しに載せることはできます。
実行しない、という制約
codopsyは、tree-sitterで構文木にしてから、複雑度とlint違反と構造を見て0〜100点とA〜Fの評価を出します。35言語に182のルールがあります。
言語サーバもコンパイラも使わず、コードの実行もしません。単一のバイナリだけで済むため、CIに置くときは「取得して一回走らせる」で終わります。型情報を使う検査ができない代わりに、対象言語を増やすのが安くなります。TypeScriptからLean 4まで同じ尺度に載る形です。
配点を隠さない
内訳は、複雑度35点、指摘40点、構造25点。Aは90点以上、Bは75点以上、Cは60点以上、Dは40点以上、それ未満がFです。
ここではっきり決めてあることがあります。警告を出すかどうかの閾値と、点数を引くときの閾値は同じものを使います。スコア専用の隠れた基準はありません。ルールを無効にすれば、指摘一覧からも点数の計算からも消えます。実際に使われた閾値は、出力されるJSONに記録されます。
ひとつの関数がひどくても、そのファイルの点をすべて奪わないよう、超過分の減点には上限が設けてあります。外れ値ひとつで赤くなる仕組みは、やがて誰も見なくなるためです。
読めなかったファイルを、満点にしない
Lean 4はマクロで構文が拡張できるため、どのような文法定義を持ってきても全部は読めません。codopsyは読める分を解析し、読めなかった部分を構文エラーとして報告します。
黙って満点扱いにしない、という点は地味ですが、自動採点を信じられるかどうかの分かれ目になります。オプションを付ければ、解析できなかったファイルがあるだけでCIを落とせます。
既存の負債は許して、新しい悪化だけ止める
いきなり全体を基準に合わせるのは現実的ではないので、運用はこうなります。
codopsy analyze . --diff origin/main --fail-on-warning
差分だけを見る形です。あるいは一度現状を基準として記録し、「今より悪くなったら落とす」に設定します。既存の負債には触れず、増やすことだけを止めます。
自分を採点する
codopsyのCIは、codopsy自身を採点し、それが基準を満たすことを要求しています。採点する側が採点に耐えないのであれば、その物差しは使われません。
品質の確認を自動化したい場合
修正生存率が「生成されたコードが残ったか」を見るのに対し、こちらは「残ったコードがどういう質なのか」を見ます。
外部に開発を委託している場合も、同じ考え方が使えます。納品物を受け取る前に一度採点し、以降は差分だけを見る。基準を決めておけば、指摘の根拠を毎回説明する手間が減ります。
