課題概要を精読する

[junseinagao]

【課題】
都道府県別の総人口推移グラフを表示するSPA(Single Page Application)を構築せよ

ワイヤーフレーム

[junseinagao]

内容

RESAS(地域経済分析システム) APIの「都道府県一覧」APIから取得する
APIレスポンスから都道府県一覧のチェックボックスを動的に生成する
都道府県にチェックを入れると、RESAS APIから選択された都道府県の「人口構成」を取得する
人口構成APIレスポンスから、X軸:年、Y軸:人口数の折れ線グラフを動的に生成して表示する

それぞれが実質的な機能要件。Issueに追加する。

[junseinagao]

制約

React/Vue.js/Angularのいずれかを用いてSPAを構築すること（バージョンはできるだけ最新版をご使用ください）

• React
• Vue
• Angular
  Nuxt.jsやNext.jsなどの、これらを内包したフレームワークの利用も許可する

環境構築の容易さ、期間の短さ、課題としてのアピールのしやすさから Next.js を採用する。

検討事項

More

• Next.jsで構築する際にSuspenseを使う

Extra

• 課題が面白かったらVue3 (vite) を使った構築も作る。
• さらに面白かったら Sveltekit を使った構築も作る。

[junseinagao]

都道府県一覧および総人口情報はRESAS APIのデータを用いること
グラフは Highcharts や Rechart.js などのサードパーティ製のグラフライブラリを用いて描画すること
ただし、グラフライブラリは上記のものに限らず、任意のものを用いてよい

Reactでグラフ描画系のライブラリを使うのは初めてなので、オススメされているものをそのまま使う

検討事項

More

• React.js の グラフ描画系ライブラリを調査する

[junseinagao]

Google Chrome最新版で正しく動くこと

.browserslistrc で指定する。

[junseinagao]

PC/スマートフォン表示に対応すること(レスポンシブデザイン対応)
ただし実機でなく、Google Chromeの検証ツールで確認できればよい

Safari対応しなくて良い。最高。

iPhone SE2 のディスプレイサイズを仮想テストデバイスにする

[junseinagao]

リンターやフォーマッターを適切に設定すること
リンターにはESLint、フォーマッターにはPrettierを使用すること

環境構築の際に、 Eslint と Prettier を設定する。

Linter/Formatterを動作させる環境

• IDE
• CI/CD

検討事項

MUST

• Eslint のルールはどうする?

課題アピールとしては、 Airbnb を採用したいところだが、慣れていない。開発スピードが落ちる恐れがある。
Next.js の 公式Docsに沿えば最低限の保守性と開発スピードが担保できそう。これでいく。

• Prettier のルールはどうする?

フォーマットが統一されていることが重要で、設定は評価項目に入っていないはず。幾つか好みの設定を入れて「設定してますよ〜。」感を出す。

[junseinagao]

styleは自分で記述し、CSS・UIフレームワークなどは原則使用しないこと
ただし、chartライブラリ内包のstyle、リセット系のCSSライブラリについてはこの限りではない
また、css-in-jsやcss-modules、sassなどのエコシステムの利用を妨げるものではなく、あくまでcssの記述力を測る趣旨に留まる

つまり、なるべく生CSSを使ったスタイリングをして欲しい。という非機能要件がある。
css-module を使う。
sass はビルド周りをイジる必要があり、一度scssで書いたコード以降が難しい特性から将来的に負債になる可能性があるため採用しない。

[junseinagao]

リードエンジニア・テックリード応募の場合は、以下も制約に加える
TypeScriptで記述すること
テストケース/テストコードを作成すること
テストツールは任意のものを用いてよい
テスト実行時にエラーが発生しないこと

自分はここには当てはまらないはずだが、課題アピールのために

• TypeScriptの使用
• Unitテスト
• できたらUIテスト

を実装する。

検討事項

テストの実装は、慣れていないため、プロトタイプからは外す?
TDDを意識して簡単なUnitテストを作成しながら開発を進める?

-> 後からテストを書くのが苦痛になる気がするので、Webテストについて学習しながら最初からUnitテストを実装する方向性で行く。

[junseinagao]

注意事項

RESAS APIの利用登録(無料)を行い、API Keyを発行する必要がある

問題なし

ソースコードはGitで管理し、作成したソースコードはGitHubにアップロードすること

Publicにして良い。と読み取れる。

Netlify / GitHub Pages / Firebase hosting / Vercel 等のホスティングサービスにデプロイし、インターネット経由で閲覧できる状態にし、そのURLを提出時に共有すること

SPAのインフラ構築に関する評価点が高くないと見える。一番簡単な方法を採用する。
また、環境構築をした時点でファーストデプロイを行っておく

-> Vercelを使用する。

セキュリティを考慮してコードを記述すること

非機能要件が曖昧だが、自分の知識から見て明らかなセキリュティリスクは対処する。

アプリのコンポーネント粒度の設計、Gitコミットメッセージやコミット粒度、ドキュメンテーション等もレビュー対象となる
チーム開発を意識してコードを記述すること

方針

• 実際に運用・継続的に開発される前提でドキュメントを用意する
• コンポーネントにおける関心の分離を意識する
• 独り相撲でPull ReqとAprove を繰り返す。

[junseinagao]

【コードの提出方法】

GitHub の public リポジトリの URL をお知らせください。
別の方法で提出する場合はご相談ください(Git のコミット履歴が分かる形式が望ましいです)。
上記の課題とは別のコード(ご自身で公開されているOSS等)をもって課題の提出とすることをご希望の場合はご相談ください。最後に、以下の三点を課題提出の際にお知らせくださいませ。
課題の取り組み開始から完了までに要した合計時間
これまでの総合的なプログラミング歴
これまでのWEBフロントエンドプログラミング歴

方針

• 別途タイマーアプリを使って作業時間を計る

[junseinagao]

経歴書から経験者とさせていただき、
提出期限は本日より 1週間後 とさせていただきます。
早く完成した場合は、その時点でご提出くださいますようお願い致します。

1週間を前提に作業計画を立てる

[junseinagao]

コーディング試験の評価ポイント

https://note.yumemi.co.jp/n/ned7429b59556

Q. ワイヤー通りに実装すればいいの？見た目は変えても良い？
A. 基本的な使い勝手さえ変わっていなければ見た目はぜひ個性を活かしたUIにしてください（かなり推奨）。

いったん、ワイヤーに忠実を目指してスタイリングする。ライブラリ系でイジりにくいところを良い感じに解釈できそう。
More で UI Good を意識したスタイリングを実装できれば評価されるはず。

Q. 完成していないとダメ？
A. ダメではないですが、マイナスポイントになってしまいます。

関係なし

Q. 提出は早いほうがいいの？
A. 実装スピードが早いことは注目に値します

Q. 提出するにあたり注意すべきところは？
A. 主に3点を提出前にご確認いただくと良いと思います。
① 必須要件を満たせているか
② チーム開発を意識してのGit/GitHubの活用ができているか
個人開発の感覚でついつい省きがちですが知識をアピールするチャンスでもあります。また、Git/Githubを用いたチーム開発未経験の場合もしっかり考慮いたしますが、あまり気にしすぎる必要はありません。
③ 使用するAPIの特徴を考慮できているか
ブラウザの開発者ツールのネットワークタブで確認してみてください。

• UIテストによるブラックボックステストがかかることを想定する
• チーム開発している想定で開発する
• APIの仕様(おそらく、リクエスト制限のことを言っている)に沿った、適切なエラーハンドリングをする

Q. リード・テックリードしか募集していないけど業務経験豊富なベテランしかダメ？
A. ゆめみでは即戦力ではなく成長率を重視しているので、他業種からの転職も歓迎です。

ポイント☝️ 提出いただいた内容に対してかかった時間とこれまでの経験年数の関係は重要視しています。

高度な知識は不要だと思いますがモダンフレームワークでの「ステート管理が適切か」 「不要なレンダリングを防げているか」「ビルドまわりの設定が適切か」などが不足しているリード職の方は お見送りとなっている

Q. サーバーサイドもできてスクリプトも得意だが、マークアップはあまり自信がないかも。問題ない？

関係なし

Q. モダンなライブラリ(ReactやVue)はあまり触ったことがなくて、プリミティブなところを勉強しているのですが問題ない？

関係なし

Q. チェックする人って何人ぐらいいるの？評価ポイントは人によって変わる？
A. 2022年3月時点でアクティブなのは9名。4〜5名ずつ週2日チェックで応募者数が多い場合は2ペア、少ない場合は4名同時で確認します

評価項目が事前に決まっていると推測できる。

• 追加のポイントに関してはドキュメントに書いてアピールしておく。

👀リンターやフォーマッターは導入されているか

ルールは任意らしい。

👀 コンポーネント分割の粒度が適切か
コンポーネントが適切に分割できているか、ディレクトリ構成が適切かを確認しています。例えば Atomic Design を活用してコンポーネント分割がされていると Good です！

Atomic Designが推奨されているような書きぶりだが、自分はこのような小規模なアプリにおいてAtomic DesignがGoodなコンポーネント分割方法だとは思わない。

• デザインドキュメントにこのコンポーネント分割の背景を書いておく。

👀 ビューとロジックが分離できているか
上記とも関連していますが、コンポーネント内でビューとロジックが混ざってしまっていないかを確認します。なるべくコンポーネントはビューのみにし、ロジックは別ファイルに定義されているとGoodです。

同上。アプリの特性に沿って最適な粒度があるはず。この意見はおそらくビジネスロジックを全てhooksに分離することを意識しているが、思想が過激すぎる。
しかし、それが評価されなのでチーム開発の視点から見ると分かりやすいルールのためこれに従う。

• プレゼンテーション層はtsxにビジネスロジック層はhooksに分離して書く

⭕ セマンティクスなマークアップができているか

意識する。

⭕ TypeScript を使っているか

❌ console.log が残っている、コメントアウトが残っていないか

• コミットからconsole.log徹底的に排除する
• Linterで制限する

❌ class でなく id 指定でスタイリングしていないか

👀 衝突の可能性が高い命名がされていないか

👆 適切にテストが記述できているか
💯 全て成功するテストが記述できているか

ここが、知識不足のため分からない。

• デグレの防止
• カバレッジレポートの生成

の2つにとりあえず着手する

🤖 CI を構築しているか

基本的にCDはVercelがまかなってくれる。

• Build成功するかをGithub ActionsでCIする。
• LintをCI上でかけてしまうと良い思いをしたためしがないので、ローカルにおけるgithooksを使ったCIで構築する。

[junseinagao]

これまでの精読をふまえた設計・実装時の方針

Must

• Next.js を採用する。
• ホスティング環境はVercelを使用する
• CDはVercelを使用する。
• Next.jsで構築する際にSuspenseを使う
• .browserslistrc で chrome@latest を指定する
• iPhone SE2 のディスプレイサイズを仮想テストデバイスにする
• huskeyとlint-stagedを使ってコミット時にCIを実行する
• スタイリングには、css-module を使う。
• TypeScriptで型安全に開発する。
• デザインドキュメント、開発ドキュメント、カバーレター、Public用のREADMEを用意する
• 一人でPull Rquestを使った開発プロセスを実行する。
• セマンティクスを意識したコーディングをする

More

• TDDで開発する
• グラフ描画系ライブラリを調査する
• UI Good を意識したスタイリングを実装する
• lighthouseスコアを高める。

Extra

• アクセシビリティを意識する。
• Vue3 (vite) を使った構築も作る。
• Sveltekit を使った構築も作る。