開発体験向上のためにやっていることをまとめた

個人開発で作成しているプロダクトが落ち着いてきたので、これまで TypeScript 環境で開発体験を上げるためにやってきたことをいくつか紹介します。

lint + コードフォーマット

少し前までは ESLint で Lint を、Prettier でコードフォーマットを行なっていましたが、ここ最近は Biome を使用しています。

Linter とフォーマッタはほぼ必須です。どちらもコードを静的に解析/修正できるツールですが、導入の目的が違います。

Linter

Linter の主な目的は、型エラーにはならないものの、コードの品質に関わる、いわゆる危険な香りがするコードを検出しようねというものです。

そのため、ルールとしては以下のようなものがあります。

• no-unused-vars: 使っていない変数や引数を禁止する
• no-explicit-any: any 型の使用を禁止する
• eqeqeq: ==の使用を禁止し、===の使用を強制する

このように、型チェックでは検知できないものの、意図しない挙動を発生させる可能性のあるコードを検知、修正することでコードの品質を向上させるのが主な目的です。

フォーマッタ

フォーマッタの主な目的は、コードの整形です。共通のコーディングスタイルを機械的に適用することで、アプリケーションの動作には全く影響のないスタイルを巡る議論に終止符を打ちます。

そのため、ルールとしては以下のようなものがあります。

• semi: 行末のセミコロンを付ける/付けない
• singleQuote: 文字列の指定をシングルクオーテーションで行うか、ダブルクオーテーションで行うか
• tabWidth: インデントの幅。タブ 2 つ、スペース 2 つなど

Biome について

改めて、 Biome にはこのような特徴があるため好んで利用しています。

1. 動作が早い

   2,104 ファイル、171,127 行のコードフォーマットでは 35 倍ほど早いようです。

   私が個人で開発しているアプリケーションではts/tsxファイルが 311 ファイルありますが、それでも十分に速度を実感するレベルでした。

2. 設定ファイルが単一で、シンプル&イージー

   Biome の設定ファイルは単一で、非常に簡素です。これまで、ESLint と Prettier は別々の設定ファイルで管理し、それらを統合してコンフリクトを起こさないようにするには追加のアドオンが必要でした。

   一方、Biomeではlintとフォーマットの機能を兼ね備えているため、単一パッケージの導入でよく、これらを統合するために別のアドオンが必要になることもありません。

導入時に、おすすめのlint設定やフォーマット設定を定義してくれるため、導入もスムーズですし、スキーマがあって補完が効くのも良いポイントですね。日本語ドキュメントがあるのも非常に嬉しいです。

テスト

テストを書くのは苦手ですが、アプリケーションの仕様を理解しやすかったり、変更の影響を検知できたりするため、AIの力を借りて頑張って書いています。

バックエンドには Vitest 、フロントエンドでは Storybook のPlay Functionを使用しています。

Vitest

いくつか選択肢がある中で、VitestはJestに比べてパフォーマンスが良いらしく、設定も簡単らしい という情報を聞きつけてVitestを使用しています。正直、全く比較はしていないのでこの辺りは他のドキュメントを見ていただければと思います。

ただ、所感としてはやはりセットアップは容易だったように感じるので、特段の理由がない場合はVitestの採用で良いのではないかと思っています。

Storybook

言わずと知れたという感じですが、フロントエンドテストでStorybook Play Functionを使用しています。

私は、テストコードを書くことにまだまだ慣れていないというのもあり、自身が書いたテストを結局手動で画面操作して確認するということをやってしまいがちです。
そこで、ユーザーの操作をトレースしてその内容が画面上で確認できるところに魅力を感じて採用しました。ユーザーの操作をトレースするのは react-testing-library などで一般的な方法ですが、それを画面上で見れるため、安心してテストを信頼することができるのが非常に体験として良かったです。

ただ、現状はCIと統合できておらず、StorybookのUI上でポチポチとテストを実行しています。現状は機能もテストケースもそこまで多くないプロジェクトなので良いですが、それが増えてくると流石に効率が悪いため、CI統合もどこかで時間を取ろうと考えています。

↓この辺りでしょうか。

もっとテストを活用して、テストをAIに書いてもらってレビュー、その実装をAIに書いてもらってレビューのような、TDD的開発手法もいずれは取り入れていきたいです。

Git 系

コミットメッセージ統一のため(&気分を上げるため)に czg を使用しています。

czgでは、CLIを使用してコミットメッセージを構築することができます。導入も簡単で、conventional commitsに従ったコミットメッセージの構築を自動化してくれるため、コミット履歴を遡りやすくなります。

私は、コミットのタイプの前に絵文字があるのがお気に入りですね。コミット履歴がカラフルでポジティブだと気分が上がります。

---

以上が今現状で私が取り組んでいることです。前述した通り、これからStorybookのCI統合も行っていきたいため、その時はまた記事を書こうと思います。

また、最近はあまり使用しておらず対象外としましたが、 Dev Container についても、AIエージェントとの協業に相性が良いイメージがあるので改めて使ってみようと思っています。