フロントエンド開発の準備
開発の前に決めておくこと
後から変更するのが難しいこと、大きな手戻りが発生する可能性のあることをできる限り開発のはじめに決めておきます。
多言語対応の有無
URLに依存する可能性が高い多言語対応は、後から対応すると制限がかかったり破壊的な変更が必要になる場合があるので、はじめに決めておきます。
多言語対応する予定はなかったけど、後から必要になってしまった場合は仕方ないと思います。
OGPの必要性
動的ルーティングに対するOGPの必要性によってレンダリング方法の選定やCDN周りの選定が変わってきます。
SEOのニーズ
こちらもOGP同様レンダリング方法に影響します。
OGPに関しては後からなんとかなることもありますが、SEOが重要なサイトの場合、そもそもSPAを選択しない方が適している可能性もあるので重要です。
対応ブラウザ/バージョン
これを明確にしないと、一部のブラウザで使用できないCSSを使用してしまったり、QAのコストが増大します。
例
| OS | OS Version | Browser | Browser Version |
|---|---|---|---|
| Windows | 11 | Chrome | 1年以内にリリースされたバージョン |
| macOS | 11以上 | Chrome | 1年以内にリリースされたバージョン |
| Safari | 1年以内にリリースされたバージョン | ||
| Android | 10以上 | Chrome | 1年以内にリリースされたバージョン |
| iOS | 15以上 | Chrome | 1年以内にリリースされたバージョン |
| Safari | 1年以内にリリースされたバージョン |
最小デバイスサイズ、ブレイクポイント
定義が曖昧だと最小デバイスサイズ以下まで意識してデザインや実装をしてしまったり、逆に小さなデバイスが考慮されていないデザインが作成しれてしまうことがあります。
レスポンシブに対する認識がずれてしまうことを防ぎます。
例
| 最小デバイスサイズ | ブレイクポイント |
|---|---|
| width: 360px | 1024px |
開発手法
これはフロントエンドだけではなくプロジェクト全体に関わることです。
開発効率に大きく関わるので認識をあわせておきます。
プロジェクト管理ツールの導入
JiraやZenhubなど高性能なツールもありますが、個人的には最近はGithub Projectsを使うことが多いです。
カンバンを使用できること、Issueに対し様々なメタデータを付与できること、Issueの親子関係や関連性を紐付けられるツールが望ましいと思っています。 (Github Projectsはこれを満たしていないかもしれませんが工夫すればそれっぽいことはできると思います。)
チームで決めたツールを決めたルールでチームメンバー全員が使用することが大切に感じています。
スキーマファースト開発
必ずスキーマファースト開発を提案するようにしています。
APIの実装を待たなくてもフロントの開発に着手できること、APIスキーマからフロントのコードを生成できることは非常に大きいです。
個人的にはOpenAPIを使用することが多いですが、プロダクトによってはGraphQLやgRPCを使用することもあります。
APIスキーマからAPI周りの型の生成、API呼び出し関数の生成、Storybookでmockをします。
APIのドキュメントはRedocなどを使用しビルドしてデプロイします。
開発環境の設定
ルールの統一の仕組み化をすることで品質の向上、レビューの手間を減らすことを目的としています。
nodeバージョン管理ツールの導入
メンバー間、開発環境とCI間などにおいてnodeバージョンによる差異をなくすためnodeバージョン管理ツールを使用します。
個人的にはvoltaが気に入っていますが、賛否あると思っています。
依存パッケージの自動アップデートツールの導入
新規開発なのに依存パッケージのアップデートをしていなかったせいで、数カ月後には負債が溜まりまくっているという状態になるのは嫌なのでできるだけ最新のバージョンにアップデートしていきます。
patchバージョンアップの自動適用、CIによる確認でできるだけ安全に自動化できることが好ましいと思います。
最近はrenovateを使用していますが、dependabotでもいいとは思っています。
tsconfig
TypeScriptの恩恵を最大限受けるためだきるかぎり厳しくします。
Eslint
特に特別な設定は必要ないと思っていますが、必ず導入します。
ESLintに限らず余計な設定は加えずシンプルに保つのが個人的には好みですが、no-unused-varsやimport/orderの設定をすることが多いです。
Prettier
戦争が起きる前にsingleQuote: true、semi: falseにしてしまいます！！！
vscode
extensions.jsonでインストール推奨のextension、setting.jsonでprettierによる整形の強制をします。
またcSpell.wordsの設定もします。
extensions.jsonはコミット対象にしなくてもいいとは思っています。
vscode以外のエディタを使っている人もいると思いますが、あまり気にしません。
あまりにもprettierによる整形が行われていないことが多かったら、別の手段を考えるかもしれません。
Storybook
addon、decoratorなどの共通設定をします。
Next、MSW、Cookieなどを使用できるようにします。
Hygen
コンポーネントの雛形を作れるように設定します。
雛形がないと実装者ごとにコンポーネントの書き方が異なり、メンテナンス性の低下やレビューの手間が増えます。
Sentry
API関連のエラーも送信することが多いです。
level、tag、fingerprintなどを設定します。
バックエンドで適切にエラーのモニタリングが行われるようになっていれば、API関連のエラーは送信しないかもしれません。
不要なエラーを飛ばしすぎるとノイズだらけになり役に立たなくなりがちなので頭が痛いです。
計測ツール
GAやGTag、それに変わるツールなど必要に応じて設定します。
Discussion