オンライン開催【シューマイ】Tech Lead Engineerから最新技術を学べ！Vue.js編
はじめに
Vue Composition APIをつかって巨大複雑コンポーネントを書き換えた体験談をします
対象は下記の方を想定しています
- 可読性の高い、クリーンな設計を行いたい
- リリースからサービスが順調に成長し中〜大規模になってきた
- Composition APIを検討している,触り始めている
やること, やらないこと
やる 
Composition APIで複雑にどう立ち向かうか、考え方の紹介
やら 
細かい実装については割愛。コードもほとんど出てこないので楽に聞いてください
ざっくりと、Composition APIがどんなものなのか掴んでいただければと思います
自己紹介
シェアフル株式会社,フロントエンドエンジニアの福田京平です。
最後に写真撮ってから一年以上髪の毛を切っていないので別人になっていますw
会社の外では個人でサービスを運営しており 、運営者ギルドというコミュニティ にも参加させていただいております。
OSSは最近あんまりできていないけど、自分でライブラリ作ったり issue立てたり翻訳をしたりです。
主にReactが多いですが雑食です。
開発者友達募集中なのでgithub:hand-dotとtwitter:labelmakeなどフォローしていただけば嬉しいです..!!
会社紹介
シェアフルはパーソルホールディングスとランサーズの合弁で作られた全く新しい会社で
1日単位のお仕事のマッチングプラットフォームを開発し提供しています。
開発チームもサービスを体現するべく、副業・フリーランスの方が多く、様々な人とモダンなフロントエンド技術で開発ができます。
1日で入って1日で抜けられる開発組織を目指しています！
技術スタック紹介
様々な技術を採用しています。言語以外にも新しいツールも入っていてモダンな環境で開発できます。
フロントはReact-Nativeでios,androidのアプリを開発していて、Nuxt.jsで求人登録するクライアント様の管理画面を作っています
もし興味がある方はwantedlyや
自分のgithubかツイッターからも絡んでいただけると...!
なぜComposition APIへ書き換えたの？
リリースからサービスが順調に成長し
MVPのプロダクトから中規模〜大規模程度になったためいくつかの問題がありました
リリースしてから時間の経過、機能の複雑化とともに求人登録画面のコンポーネントがとんでもないことに...
- 機能追加に対して速度がでない
- 開発しているのか壊しているのかわからなくなる
- コンポーネントがデカすぎて新人さんにこういうこともありますよね みたいな顔される
どうにかしないと..
最初はあんなに可愛かったコンポネントさん、少し目を離したらどうしちゃったんだろうね？
- 読みにくい
- メンテナンスしにくい
- 再利用しにくい
時間の経過と共に大規模に,機能の追加に伴って複雑化していくコードに対して
なんらかのアプローチが必要でした
具体的になぜComposition APIなの？
シェアフルでは一年近く前からComposition APIを導入し少しずつ書き換えています。
大規模開発で弱いと言われていたVueでComposition API化し、
- 型推論
- 関心の分離
の観点でコードの品質を高めることができます。
(Composition APIは一部に導入,既存のコードと併用ができます)
この巨大複雑コンポーネントどうしてこうなっちゃった？
Composition APIで何をするかではなく、一歩下がって何故この巨大複雑コンポーネントができあがったのでしょうか？
一般的な流れを検索コンポーネントを例にみていきましょう。
純粋無垢なサーチ
並び替えを要求された元サーチ
要求は続く
- ページング
- お気に入り検索条件
- 検索履歴
- etc...
あちこちに新機能のためのコードが散らばります。
サーチ、最近変わったよねと噂されみんなから距離をおかれるコンポネントに...
どうすればよいのか？
機能・関心（何をしたいのか）毎に分離し整理する必要があります
さきほどのサーチをComposition API化するとこのようになります
さらに"検索"と"並び替え"のロジックを別のファイルに切り出す
Composition APIで書き換えて関心に基づいて分離し、ファイルを分けることで
コンポーネント内をあちこちジャンプしなくても何で構成されているのかわかります。
銀の弾丸はない
Composition APIをつかうことでコードを整理しやすくなりますが、元のコードに比べてファイル数は増えるし、コードは少しだけ冗長になります。
Composition API はコード品質の上限を上げる一方で、下限を下げることにもなります。
というのは、これまでのOptions-based APIに比べるとフレームワークの部分が薄くなり、自由度が増すためです。
Vueコンポーネントから剥がしたTypescriptファイル中心の開発にすることで求められるのはシンプルなプログラミング力と設計力。
逆にいうと整理されたTypescriptのコードを書くことはComposition API を使うことで整理されたVueコードを書くスキルに直結します。
共通認識
自分が大事だと思ったのは、
単にコードの書き方をComposition APIにするのではなく、
今後のためにコードを綺麗な形に保ちやすくしようというチームの共通認識です。
具体的なアクションとしてシェアフルでやったことはモブプロを行ってみんなで書き換えていくことをやりました。
モブプロの振り返りの中で有識者へ質問ができる環境をつくって共通認識を育てていく。
関心に基づいて分離していくのは一定の経験が必要になってくる場合もあるので、レビュワーは判断ロジックを明文化したり、説明することでチーム全体で同じ美意識を持てると考えています。
振り返って(サービス観点)
- 巨大コンポーネントが分離されたことで見通しの良さが明らかに上がった
- 読み方を知っていれば、関心に基づいて整理しているのでファイルが増えてもコードが増えても**精神的に絡み合ったコードが減ったように感じることができる
- フレームワークから分離するので単体テストがしやすい
- 一気にリファクタして一斉リリースではなく、毎回のリリースにComposition API化したものを少しづつ入れていく感じで書き換えています
振り返って(プログラマ観点)
ReactのHooksもそうだけどフレームワークからthisが取り除かれ、
結果としてフレームワークが魔法的なものから、よりシンプルで薄いものになってきた印象。
Vue,Reactは魔法ではなく、仮想DomはめっちゃすごいinnerHTMLなんだということを再認識させられる
これからは「フレームワーク力」よりも「プログラミング力」の方が大事になってくるかなと思っています。
フレームワーク任せにしない設計力も重要になってくると感じました。
興味をお持ちいただけたら
導入は @vue/composition-api を追加することで、Vue2系でも簡単に使用できますのでぜひお試しあれ！
ドキュメント
RFC: https://composition-api.vuejs.org/
API: https://composition-api.vuejs.org/api.html
Back to basics
基礎に戻ってVueのこの先の進化もみんなで楽しんでいきましょう！
Clean Architecture
Code Complete
参考資料:
ありがとうございました
福田京平