jevのlinterがでてきた！ コードの命名・コメント・テストが実装内容とズレがないかを高速・安価に確認できるLinterだ 例えば、以下のような問題を見つけられる ・calculateTotal という関数が、合計を計算するだけでなく注文データまで保存している ・safeParseConfig という名前なのに、不正な設定を渡すと例外を投げる ・「同じ通知を二重送信しない」というテストが、通知処理を1回しか呼んでいない ・「5秒でタイムアウトする」というコメントがあるのに、実装では30秒に設定されている コードは正しく動いていても、名前やコメントが実装と異なることはよくあるが、これまではLLMでレビューコストをかけたり、人間が見つけるしかなかった jev-lintは、こうした意味のズレをAIで検査してくれるため、人間のレビュー負荷を下げてくれる これまでのLintや型チェッカーを置き換えるものではなく、それらに足りないものを補完してくれるLinterだ 構文や型、決められたパターンなど、機械的に判定できる問題は既存のツールに任せ、判断が必要な部分をjev-linterが担ういうjevの役割分担通りの使い方ができる 現在用意されている標準ルールは以下のとおり ・fn-name-promises 関数の処理が、名前から期待される内容と違っていないか ・var-name-describes-value 変数名が、実際に入っている値を正しく表しているか ・test-name-describes-code テスト名と、実際に実行している内容が一致しているか ・test-name-verifies-claim テスト名が主張している動作が壊れても、テストが通ってしまわないか ・module-name-describes-contents ファイル名やモジュール名が、中身の役割を表しているか ・module-naming-consistent 同じモジュール内の似た操作に、一貫した名前が付いているか ・safe-name-is-safe safe、try、OrNullなどと付いているのに、失敗が例外として外へ漏れていないか ・idempotent-name ensure、upsert、registerなどと付いているのに、繰り返し呼ぶことで余計な変更が発生しないか ・pure-name-is-pure compute、format、parseなどと付いているのに、外部の状態を読み書きしていないか ・test-mocks-subject 本番コードを検証しているように見えて、実際にはモックが返した値だけを確認していないか ・snapshot-only-behaviour-claim 特定の動作を検証すると書いてあるのに、スナップショットしか確認していないか ・comment-describes-declaration 関数や変数の上にあるコメントが、現在の実装と一致しているか ・comment-describes-block 処理の途中にあるコメントが、その直後のコードを正しく説明しているか ・log-level-matches-event 失敗なのにinfo、通常の処理なのにerrorなど、ログレベルが処理内容と食い違っていないか ・script-name-does package.jsonのscript名と、実際に実行するコマンドが一致しているか さらに、プロジェクトに合わせて独自ルールも追加できる 例えば、以下のようなルールを追加できる ・デバッグメッセージの内容と、実際に出力している値が一致しているか ・プロジェクト固有のアンチパターンが含まれていないか ・独自の命名規則と実装が一致しているか ・特定の処理に必要なエラー対応が抜けていないか