# プロジェクト概要
不動産オーナーとポップアップストアや展覧会をやりたい人をマッチングするサービスの開発をしています。
エンジニア10人で開発していたこともあるし、チームが分割して5人になったりとチーム規模は色々変わっていきました。
新卒で入社して1年半ほどはバックエンド・フロントエンドどちらの開発も行っていました。
フロントを得意とする人間が社内からいなくなったことをきっかけにフロントエンドに力を入れるようになりフロントエンドエンジニアとなりました。
今年リードエンジニアになり、 レビュー、フロントエンドの技術選定、フロントエンドのインフラ周り(vercelが主)、新卒教育、採用面談など行なっております。また、バックエンド・フロントエンド含めたチームのリーダーにもなり、2年ほど離れたバックエンドのキャッチアップも再度行い始めました。
あとは事業説明を二週間に一度マネージャーにみてもらい事業理解を深めています。
## 仕事を進める上で気をつけていること
**保守性と開発速度の折り合いをつける**
チームの規模・事業のフェーズによって求められることが変わり、それに応じた開発をできることがとても重要だと思います。第一優先するべきなのはユーザーに価値を届けることです。どれだけ綺麗なコードを書いても機能を提供できなければただの自己満足で終わると思っています。
実際に弊社のバックエンドの開発においては、オニオンアーキテクチャや、クリーンアーキテクチャなど色々な手法を参考に責務を細かく分割しそれごとにテストを書くという実装をしていましたが、Rails wayに沿って書けば1時間で終わるようなタスクに3時間ほど時間を使ってしまうなど保守によりすぎてユーザーになかなか価値が届けることができないという問題がありました。
ここの部分を単純なGETのリクエストに関してはRails wayに沿ってcontrollerに直接ロジックを書くなどして緩和したり工夫を行ないました。
## 使用技術・ライブラリ
rails, react, nextjs, react-query, redux, react-hook-form, recoil, tailwind, styled-components, emotion, laravel, vercel...
いろいろな技術を導入して良し悪しを経験してきました。
大きくやってきたことを説明して行きます。
## Railsで作られたプロジェクトをNext.jsでリニューアル
ここで初めてNext.jsに触れました。当時はバックエンド寄りの技術スタックでしたが調べながら気合いでリニューアルを行いました。相談する相手が社内にいなかったためNextjs導入の部分はすべて1人で調べて行いました
### 問題点
SPのPageSpeedInsightの結果が6-9点であること
使用技術がレガシーであること
### やったこと
全体を置き換えるのは不可能だったのでSEO的に重要になるページだけ置き換えました。
nginxを前に置くのではなく一番上にnextjsを置いてconfigにリダイレクト条件を記述してリバースプロキシのような役割を持たせました。
nginxを前に置かなかった理由はnextjsのissueを探したところ公式がnginxではなくて先にnextjsを置いてくれって書いていたからです。
### 学び
PageSpeedInsightの点数を上げることについて
- First Viewに表示されない要素全て遅延読みさせる
- 画像について全てasyncをつけていればいいだろうと思っていたが、first viewに表示される画像にはつけてはいけない
- scriptタグの読み込み順がかなり重要(GAタグ消しただけでPC 100点になった)
その他
- react-query, react-hook-form, yup の使い方
- ISR,SSG,SSRの使い分けについて。(ISRを使った)
- componentの共通化・メモ化について
>ISR,SSG,SSRの使い分けについて
ここについては、最初すべてのページをビルドする対象としてしまいデプロイするのに40分ほどかかっていました。アクセスが多い上位のページだけを初回ビルドの対象とし、他は初回アクセスが来てからビルドするような工夫を行いました。
>componentの共通化・メモ化について
かなり前ですが記事を書きました。
https://zenn.dev/tsukunin/articles/4b41bce046ba74011cf4
useMemo, useCallback, memoを脳死で行うのではなく、どうして行うのか、本当に意味のあるmemo化なのかということを意識するようになりました。
また共通化をやりすぎて使い辛いcomponentを作るようなことも多く、反省をしました。
共通化することによって逆に可読性を下げてしまうパターンがあるということを学び、正しい共通化ができるよう心がけています。
### 結果
PCについては80-90点代、SPについては50-60に回復させることに成功しました。
ですが、GAのタグの読み込み方にまだ改善の余地があると思っており課題だと思っています。
## OpenAPIの導入
バックエンドの開発が終わるまでフロントエンドの開発が進めれないってことや、APIのレスポンスに関する型定義が本当に正しいのかということがわからない問題などがありその問題を解決するために導入しました。
## 自社componentライブラリの作成
新しいrepositoryを作るたびに同じようなReact componentが作成されていて効率が悪かったのでComponentライブラリを作成しました。
## フロントエンドテストの導入
こちらは現在進行形で行なっております。
あまりにテストを書きすぎると開発速度が落ちてしまうため最初は各場所を限定しています。
フロントエンドのテストにおいて、カバレッジを100%を目指したり、単体テストを多く書いたりmockをたくさんしたりとかはアンチパターンだと思っているので結合テストをメインで書くことにしようとしています。mockをやりすぎるのは良くないというのはテストの信頼度が下がるというところから来ています。
apiのmockはprismとmswどちらを使うか迷いましたが、mockをできる限りしないという観点からネットワークレベルでmockできるmswを選びました。
現在はよくエラーが起こるform周りに対して書き始めています。
テストを導入したことでどうなったとかまだ効果は実感できていませんが、テストについて考えるいい機会となりました。