AIの書いたコードの手直しを減らすお作法

AI にコードを書かせた後、余計なコードを見つけて消す作業があります。
不毛なことなので、それらの作業を減らすためのお作法を紹介します。

未使用コードを消す

以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。

個人サイトリニューアルの振り返り

個人サイト（ジブンノート）をリニューアルしました。本記事では、個人サイトをリニューアルした際にあった出来事などを振り返りたいと思います。ちなみに、個人サイトは以下のページです。ノート風デザインで、ブログ記事が読めるようになりました！🎉

ジブンノート

Git の pre commit 時に knip を動かして未使用ファイルを削除するように強制します。
これにより、使われていないコードや未使用な npm package などを消すことができます。
プロジェクトごとに、 knip の設定ファイルを書く必要があります。

文言を1ファイルにまとめる

AI にコードを書かせると、テキストが他のページと合わない用語を使ったりします。
そういった用語を手直しするのが不毛です。
そこで以下の記事でも触れている通り、画面表示などに使用する文言を言語ファイル( ja.json )として管理します。

多言語対応しなくても i18n を入れる理由は、表記揺れをなくすため

多言語対応を予定していない場合でも、i18n ライブラリを導入し、文言をメッセージファイルで管理しておく方法があります。 この方法を取ると、表記揺れに気づきやすくなるという利点があります。 この記事では主にフロントエンドの文脈で話を進めます

ジブンノート

その上で、ESLint の設定で 直接テキストを使用できないようにします。
例えば、jsx-no-literals が手っ取り早いでしょう。
これを導入することで、表示するテキストの表記揺れの修正が言語ファイル内で完結します。
そうすると、AI から比較的マシなテキストを書き上げてくれます。
また良くなかった場合も、文言ファイル内の修正だけに止まるため修正が楽になります。

変更前に戻せる状態にする

よく AI にコードを書かせていると、試行錯誤によって無駄なコードが生まれることがあります。
基本的に、変更前に戻せる状態を意識しておくと楽です。
うまく行っている状態までをステージに上げておくのです。
こまめにコミットしちゃうのが良いのですが、そうはいかない場合もあります。
そういう場合うまく行っている状態の箇所をステージにあげておけば、AIのコードがNGだった場合にコードをリセットできます。

pre commit を厚くする

pre commit 時に、さまざまなチェックを入れておくと安全です。
私の場合は、以下の npm script の ci:fix を pre commit に通すようにしています。

{
  "scripts": {
    "ci:fix": "pnpm knip:fix && pnpm lint:fix && pnpm format && pnpm check-types && pnpm test:fix",
    "knip": "knip",
    "knip:fix": "knip --fix",
    "lint": "eslint . --max-warnings 0",
    "lint:fix": "pnpm lint -- --fix",
    "format": "prettier --write \"**/*.{ts,tsx}\"",
    "check-types": "tsc --noEmit",
    "test": "vitest --run",
    "test:fix": "pnpm test -- --update"
  }
}

knipの未使用コードの削除、lintのチェック、formatで整え、check-typesで型チェック、テストの実行です。
テストにはvitest のテストだけでなく、storybook のテストを実行しています。
Storybook を Vitest Browser Mode で Visual Regression Test （以下、VRT）します。 詳しくは、以下の記事をご参考ください。

Storybook の Story を Vitest Browser Mode with Playwright で VRT

Storybook の Story オブジェクトを Vitest の Browser Mode だけで、Visual Regression Test（VRT）ができるようになりました。 本記事では、その導入手順をコンパクトに紹介します。 前

ジブンノート

VRTに加えて、Storybookのa11yも導入しておきます。

• Accessibility | Storybook integrations - storybook.js.org

a11yのテストを動かしておくと最低限のa11yのエラーを見つけることができます。
例えば色のコントラストなどが多いです。
いちいち指摘せずとも、テストでエラーになれば AI 側で修正してくれるようになります。

Lintの設定は、自身が手直しをよくするものはLintで対応できるならやっておきます。
例えば、Propsなどの並び順は気になる場合は それらを強制する設定を登録しておきます。

その他

あとは、『classNameを使わせない』という強硬策を取ることもあります。
className で自由にスタイルを書かせると、AI がデザインシステム外のスタイルで仕上げてくることがあります。
基本的に、デザインの最終調整は人間の目でやるべきと思いますが、土台はある程度 AI に書かせたいです。

そこで、ESLintの設定で className を使用させない設定を取り入れます。
設計次第ですが、以下のようなルールで縛っておけば楽です。

• AtomicなUIのみ、className の使用を許可する
  • 例: Typography, Layout（Stack, Container, ...）, Button, ...
  • class-variance-authority を使用し、UIのバリエーションを定義する
• それ以外のUIは、 AtomicなUI を使うようにする

終わりに

これらのお作法を守っておくと、AI のコーディングからの手直しを比較的減らせることができます。
より効率的に開発していきましょう。

s

silverbirder

Webソフトウェアエンジニア