取り組んだものは下記です。
応募する予定はありませんが、フロントエンドの素振りの課題としては面白そうと思って取り組んでみました。
やってみた感想として、適切に作ろうと思うと意外に設計に頭を使うのと、Unit Test の経験値がないことを突きつけられて面白かったです。 自分にはフロントエンドの実務経験が一切ないので、自分の中でバラバラに知見があった ESLint や Prettier、husky や GitHub Actions をアプリケーション開発の中で使用する、経験が得られてよかったです。
また、コミットやブランチの運用も採点対象になるそうなので、普段ものすごい雑にやっていたコミットやブランチ運用に緊張感を持って、他人が見ることを意識して取り組めました。
テストは 100％カバレッジを通そうとしましたが、モチベーションが尽きてしまったのでこれで終了です。
------------------|---------|----------|---------|---------|------------------- File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s ------------------|---------|----------|---------|---------|------------------- All files | 97.22 | 97.43 | 95.23 | 97.22 | src | 100 | 100 | 100 | 100 | setup.ts | 100 | 100 | 100 | 100 | src/components | 100 | 100 | 100 | 100 | Chart.tsx | 100 | 100 | 100 | 100 | Prefectures.tsx | 100 | 100 | 100 | 100 | Title.tsx | 100 | 100 | 100 | 100 | src/lib | 95.02 | 95.83 | 100 | 95.02 | client.ts | 100 | 100 | 100 | 100 | constants.ts | 100 | 100 | 100 | 100 | hooks.ts | 84.84 | 92.3 | 100 | 84.84 | 21-24,45-46,49-52 src/test | 100 | 100 | 80 | 100 | utils.ts | 100 | 100 | 80 | 100 | ------------------|---------|----------|---------|---------|-------------------
成果物
着手して 10 日ぐらい経っているが、実動は 24 時間 ( 3 日 ) ぐらい。本業が忙しかったり体調を崩してなかなか進めなかったのと、 Vitest の設定にちょっと苦戦したので思ったより時間がかかってしまった。
population-app-iota.vercel.app
注意した点
dependencies を最小にする
- 脆弱性を極限まで減らすため。また、依存関係をシンプルにして React の知識があれば誰でも読み解けるようにするため
- 基本的に Web API、React の API だけ使って構築する。
Reduxも使わない - グラフは自作するのが大変なので
rechartsを使った - 最終的に 3 つのライブラリだけ
dependenciesになった
Linter と Formatter の設定
- プロジェクトを作ったら 2 コミット目で設定完了するぐらいの勢いで早めにやっておいた
huskyとlint-stagedを使ってローカルで自動実行できるようにした- Unit Test と違ってこの辺りは実行環境に影響されないため
- 手動実行を信じない、CI の Lint や Formatter で弾かれないようにした
Unit Test
- テストと実装をセットで考えた
- Jest に近い API の
Vitestを使ってみた - 基本的にテストしやすい形で書くので、関数の責務を小さくする必要があった
- 引数や返り値を適切に設計する必要があった
- React をテストするのに
@testing-library/*系のテストライブラリの使い方を理解した
CI/CD の設定
- CI は GitHub Actions で設定
- 適切にキャッシュを使って実行サイクルを速く下
- 各ステップ毎に
nameを振ってどこまで終わったかを分かりやすくした - 実行環境に左右されないように、Unit Test は CI で実行し、ローカルでは実行しない方針にした
- Node.js ではあまり影響はないと思うが、実行環境を統一することでトラブルを減らした
- CD は Vercel で設定
- お金をかけたくなかったのと、設定が楽なので採用した。Pull Request にプレビューホスティングされるのありがたい
- API キーを漏らさないために、ローカルでは
.env.localを、CI/CD では環境変数から API キーを渡すようにした- アプリケーションを Chrome の開発コンソールの Network タブを見てしまうとバレてしまうが仕方ない
反省点
- モックを適切に使ってカバレッジ 100％にしたかったが、できなかった。もっと簡単な例で素振りをする
- Custom Hooks が汎用性のない、ロジックの切り出しになったため、再利用性が薄くなってしまった
- 重複したところも多い。また、適度な抽象化を行いたい
- Prop Drilling になってしまったため、素直に
React.createContext()でコンテクストを使えばよかった - テストの書き方も Example を見つつ書いているが、どこまで書けばいいかわからなかった
- ここら辺は実務経験がないことがネックになっていると感じる
- とはいえこれはグループ毎に文化が分かれていそう
まとめ
テックリード職を前提として取り組んだが、フロントエンドのテックリードなら 1 つの JavaScript フレームワークに精通して、Unit Test のテストフレームワークの使い方や書き方を覚えていて当然とは感じた。
複数の JavaScript フレームワークを知っていることより、Linter、Formatter、Unit Test を CI 上に乗せて一連の流れを構築できる方が、開発する側としては大事だと改めて感じた。
個人的に TypeScript に関しては「型があるから JavaScript」より難しいとは思わず、寧ろ実行する前にエラーになる原因が明らかになる点で JavaScript よりは難易度が低いと思っている。
当初の目論見通り、JavaScript のフレームワークの素振りとしてはよかった。
個人だと、どうしても動けばいいレベルで、あまり複雑にならないためテストがおざなりになってしまうので、いい勉強になった。
