Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Vue.js + TypeScriptによる 新規サービス開発の振り返り/frontend-l...

hatsune
October 28, 2020

Vue.js + TypeScriptによる 新規サービス開発の振り返り/frontend-looking-back

Meetup資料

hatsune

October 28, 2020
Tweet

More Decks by hatsune

Other Decks in Programming

Transcript

  1. #RAKUSMeetup
 自己紹介
 • 北嶋 初音 / Hatsune Kitajima
 • 経歴


    ◦ 2016年4月:Web系のITベンチャーに新卒入社
 ◦ 2020年1月:ラクスに中途入社
 • 現在
 ◦ ラクス初のフロントエンドエンジニア
 ◦ 新規サービス(楽楽勤怠)の機能開発を担当
 ◦ フロントエンド組織のベース作り

  2. #RAKUSMeetup
 開発体制 - 開発フロー
 FEエンジニア
 
 画面実装
 BEエンジニア
 
 API仕様書作成


    UIデザイナー
 
 デザイン作成
 PdM
 
 要件仕様書作成
 BEエンジニア
 
 API実装

  3. #RAKUSMeetup
 開発体制 - 開発フロー
 FEエンジニア
 
 画面実装
 BEエンジニア
 
 API仕様書作成


    UIデザイナー
 
 デザイン作成
 PdM
 
 要件仕様書作成
 BEエンジニア
 
 API実装
 ・FE,BEが並行開発
 ・APIは初めはモック
 ・実装後に繋ぎ込み

  4. #RAKUSMeetup
 開発体制 - 良かった点
 • SPA
 ◦ 最小限のデータのやりとりでOK
 ◦ スムーズなUI/UXを実現できる


    • Web API
 ◦ SPAと相性が良い
 ◦ FEのモダンなフレームワークを利用しやすい
 ▪ 楽楽勤怠ではVue.js採用
 ◦ 再利用ができる
 ▪ PC版・スマホ版で同じAPIを呼べばOK

  5. #RAKUSMeetup
 開発体制 - 良かった点
 • BE,FEを分けて開発
 ◦ それぞれの作業に集中できる
 ◦ FE的には


    ▪ デザインの再現、画面表示・動作に注力できる
 ▪ APIのインターフェースだけ把握しておけばOK
 ◦ BE,FEが並行開発できる
 ▪ 開発スピードが早い(工数削減)

  6. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ FEが要件仕様書・デザイン・API仕様書のすべてをウォッチする必要が あり、変更に気付けないときがある
 ◦

    【対応】ウォッチできる仕組みを作る必要がある
 ▪ 現状は変更者が忘れないように通知するしかない
 ▪ 例)チャットに自動投稿するなど

  7. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ デザインだけでは細かい挙動は読み取れない
 ◦ FEで要件仕様書・デザイン・API仕様書を組み合わせて、動作を想像し

    て実装する必要がある
 ◦ 実装者以外が動作の正当性を分からない(レビューできない)
 ◦ 【対応】画面仕様書を作成する
 ▪ 細かい動作について記載した資料を作る
 ▪ 実装前にデザイナーや要件定義者のレビューを挟む

  8. #RAKUSMeetup
 開発体制 - 辛かった点
 • 開発フロー
 ◦ FEでAPI仕様書を参考にAPIモックを作成しなければならない
 ◦ localで各自JSONサーバーを立ち上げて対応


    ◦ 正常系・異常系の全パターン網羅などがつらい
 ◦ API変更時の出戻りが大きい
 ◦ 【対応】OpenAPIでモックサーバーを立てる
 ▪ npmかDockerで定義ファイルからモックサーバーを立てられない か調査中(参考:swagger-typescript-codegen)

  9. #RAKUSMeetup
 利用技術 - フロントエンド開発
 • Vue CLI(4.0.5)
 ◦ Babel
 ◦

    TypeScript
 ◦ SCSS
 ◦ Vuex
 ◦ Vue Router
 ◦ Vuetify
 ◦ ESLint
 ◦ Prettier

  10. #RAKUSMeetup
 利用技術 - 良かった点
 • Vue.js
 ◦ コンポーネント化
 ▪ 基底コンポーネントが再利用可能


    ▪ 開発が進むほど実装スピードが上がる
 ▪ PC版・スマホ版でも別スタイルを当てるだけで済む
 ▪ scopedなCSS記述が可能
 ▪ アトミックデザインとの相性が良い
 ◦ 高度なUI/UXの表現が可能

  11. #RAKUSMeetup
 利用技術 - 良かった点
 • TypeScript
 ◦ 型指定で安全な開発が行える
 ◦ エディタの補完機能が効く


    ◦ ドキュメントとしても機能する
 ▪ 例)メソッドに型指定があると使い方が分かる

  12. #RAKUSMeetup
 利用技術 - 辛かった点
 • TypeScript
 ◦ Vue.jsとの相性の悪さ、型が衝突する
 ◦ anyや!で型指定から逃げてしまっている所が多い


    ▪ 既存箇所は徐々に指定していくしかない
 ▪ 【対応】最終的にはlintではじく
 ◦ API仕様書の変更に気付けないと型定義がずれる
 ▪ 【対応】定義ファイルから型生成する仕組みを導入する
 ◦ enumの利用が推奨されていない
 ▪ 【対応】Union Types + as constに置き換える

  13. #RAKUSMeetup
 利用技術 - 辛かった点
 • Vuex
 ◦ Storeで持つべきでない値を持ってしまっている
 ▪ グローバルな値なので、最小限にすべき


    ▪ 【対応】local変数に移動する
 ◦ 他画面でfetchした情報がクリアされておらず、別画面に影響を与えて いる
 ▪ 今までは遷移前に画面で利用したModuleの情報をクリア
 ▪ 【対応】画面で利用するModuleを画面呼び出し時にクリア

  14. #RAKUSMeetup
 利用技術 - 辛かった点
 • Vue router
 ◦ 履歴管理が大変
 ▪

    historyに積む?積まない?
 ▪ 【対応】画面仕様書に記載する
 ◦ URLのparamを直接参照していると、画面間を高速遷移時に別画面の 同名のparam値でAPIを叩いてしまう
 ▪ 【対応】ローカル変数に代入することで対応

  15. #RAKUSMeetup
 利用技術 - 辛かった点
 • パフォーマンス
 ◦ SPAなので初期表示のパフォーマンスが悪い
 ▪ 特にテーブル(複数API、要素数が膨大)


    ▪ 【対応】要素の描画を段階的に行うことで回避
 ◦ 基底コンポーネントがリッチになるとパフォーマンスが劣化する
 ▪ 基底コンポーネントはVuetifyをラップしたもの
 ▪ 【対応】使っていない機能が多いので、オリジナルのものに置き換 えていくと良さそう

  16. #RAKUSMeetup
 利用技術 - 辛かった点
 • テストコードがない
 ◦ リファクタリング時などにデグレが発生が検知できない
 ▪ 【対応1】テスト環境(jest)の導入


    ▪ 【対応2】自動テストの仕組みを作成(CI)
 ◦ テストを意識したコーティングになっていない
 ▪ Vueファイルにロジックを持ちすぎている
 ▪ 【対応1】helperファイルにロジックを移行
 ▪ 【対応2】Vue3.0への移行、ドメイン駆動思想の導入
 • Composition API