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

by hatsune

Slide 1

Slide 1 text

Vue.js + TypeScriptによる  新規サービス開発の振り返り  株式会社ラクス  開発本部第一開発部 UI開発課  北嶋初音 

Slide 2

Slide 2 text

#RAKUSMeetup  自己紹介  ● 北嶋初音 / Hatsune Kitajima  ● 経歴  ○ 2016年4月：Web系のITベンチャーに新卒入社  ○ 2020年1月：ラクスに中途入社  ● 現在  ○ ラクス初のフロントエンドエンジニア  ○ 新規サービス（楽楽勤怠）の機能開発を担当  ○ フロントエンド組織のベース作り 

Slide 3

Slide 3 text

#RAKUSMeetup  楽楽勤怠  ● 2020年10月1日に無事リリース  ● 今後も新機能を続々追加予定 

Slide 4

Slide 4 text

#RAKUSMeetup  今日お話しすること  楽楽勤怠の開発初期〜リリースまでの振り返り  開発体制  利用技術  今後の開発 

Slide 5

Slide 5 text

開発体制 

Slide 6

Slide 6 text

#RAKUSMeetup  開発体制 - エンジニア  ● SPA（Single Page Application）を採用  ● FE・BEを分けて開発（社内初）  FE  画面表示  BE  Web API  Ajax通信 

Slide 7

Slide 7 text

#RAKUSMeetup  開発体制 - 全体  FEエンジニア(4)  BEエンジニア(6)  PdM(1)  UIデザイナー(2) 

Slide 8

Slide 8 text

#RAKUSMeetup  開発体制 - 全体  FEエンジニア(4)  BEエンジニア(6)  PdM(1)  UIデザイナー(2)  FE,BEを分けて開発 

Slide 9

Slide 9 text

#RAKUSMeetup  開発体制 - 開発フロー  FEエンジニア    画面実装  BEエンジニア    API仕様書作成  UIデザイナー    デザイン作成  PdM    要件仕様書作成  BEエンジニア    API実装 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

#RAKUSMeetup  開発体制 - 良かった点  ● SPA  ○ 最小限のデータのやりとりでOK  ○ スムーズなUI/UXを実現できる  ● Web API  ○ SPAと相性が良い  ○ FEのモダンなフレームワークを利用しやすい  ■ 楽楽勤怠ではVue.js採用  ○ 再利用ができる  ■ PC版・スマホ版で同じAPIを呼べばOK 

Slide 12

Slide 12 text

#RAKUSMeetup  開発体制 - 良かった点  ● BE,FEを分けて開発  ○ それぞれの作業に集中できる  ○ FE的には  ■ デザインの再現、画面表示・動作に注力できる  ■ APIのインターフェースだけ把握しておけばOK  ○ BE,FEが並行開発できる  ■ 開発スピードが早い（工数削減） 

Slide 13

Slide 13 text

#RAKUSMeetup  開発体制 - 辛かった点  ● 開発フロー  ○ FEが要件仕様書・デザイン・API仕様書のすべてをウォッチする必要があり、変更に気付けないときがある  ○ 【対応】ウォッチできる仕組みを作る必要がある  ■ 現状は変更者が忘れないように通知するしかない  ■ 例）チャットに自動投稿するなど 

Slide 14

Slide 14 text

#RAKUSMeetup  開発体制 - 辛かった点  ● 開発フロー  ○ デザインだけでは細かい挙動は読み取れない  ○ FEで要件仕様書・デザイン・API仕様書を組み合わせて、動作を想像して実装する必要がある  ○ 実装者以外が動作の正当性を分からない（レビューできない）  ○ 【対応】画面仕様書を作成する  ■ 細かい動作について記載した資料を作る  ■ 実装前にデザイナーや要件定義者のレビューを挟む 

Slide 15

Slide 15 text

#RAKUSMeetup  開発体制 - 辛かった点  ● 開発フロー  ○ FEでAPI仕様書を参考にAPIモックを作成しなければならない  ○ localで各自JSONサーバーを立ち上げて対応  ○ 正常系・異常系の全パターン網羅などがつらい  ○ API変更時の出戻りが大きい  ○ 【対応】OpenAPIでモックサーバーを立てる  ■ npmかDockerで定義ファイルからモックサーバーを立てられないか調査中（参考：swagger-typescript-codegen） 

Slide 16

Slide 16 text

利用技術について 

Slide 17

Slide 17 text

#RAKUSMeetup  利用技術 - フロントエンド開発  ● Vue CLI（4.0.5）  ○ Babel  ○ TypeScript  ○ SCSS  ○ Vuex  ○ Vue Router  ○ Vuetify  ○ ESLint  ○ Prettier 

Slide 18

Slide 18 text

#RAKUSMeetup  利用技術 - 良かった点  ● Vue.js  ○ コンポーネント化  ■ 基底コンポーネントが再利用可能  ■ 開発が進むほど実装スピードが上がる  ■ PC版・スマホ版でも別スタイルを当てるだけで済む  ■ scopedなCSS記述が可能  ■ アトミックデザインとの相性が良い  ○ 高度なUI/UXの表現が可能 

Slide 19

Slide 19 text

#RAKUSMeetup  利用技術 - 良かった点  ● TypeScript  ○ 型指定で安全な開発が行える  ○ エディタの補完機能が効く  ○ ドキュメントとしても機能する  ■ 例）メソッドに型指定があると使い方が分かる 

Slide 20

Slide 20 text

#RAKUSMeetup  利用技術 - 辛かった点  ● TypeScript  ○ Vue.jsとの相性の悪さ、型が衝突する  ○ anyや!で型指定から逃げてしまっている所が多い  ■ 既存箇所は徐々に指定していくしかない  ■ 【対応】最終的にはlintではじく  ○ API仕様書の変更に気付けないと型定義がずれる  ■ 【対応】定義ファイルから型生成する仕組みを導入する  ○ enumの利用が推奨されていない  ■ 【対応】Union Types + as constに置き換える 

Slide 21

Slide 21 text

#RAKUSMeetup  利用技術 - 辛かった点  ● Vuex  ○ Storeで持つべきでない値を持ってしまっている  ■ グローバルな値なので、最小限にすべき  ■ 【対応】local変数に移動する  ○ 他画面でfetchした情報がクリアされておらず、別画面に影響を与えている  ■ 今までは遷移前に画面で利用したModuleの情報をクリア  ■ 【対応】画面で利用するModuleを画面呼び出し時にクリア 

Slide 22

Slide 22 text

#RAKUSMeetup  利用技術 - 辛かった点  ● Vue router  ○ 履歴管理が大変  ■ historyに積む？積まない？  ■ 【対応】画面仕様書に記載する  ○ URLのparamを直接参照していると、画面間を高速遷移時に別画面の同名のparam値でAPIを叩いてしまう  ■ 【対応】ローカル変数に代入することで対応 

Slide 23

Slide 23 text

#RAKUSMeetup  利用技術 - 辛かった点  ● パフォーマンス  ○ SPAなので初期表示のパフォーマンスが悪い  ■ 特にテーブル（複数API、要素数が膨大）  ■ 【対応】要素の描画を段階的に行うことで回避  ○ 基底コンポーネントがリッチになるとパフォーマンスが劣化する  ■ 基底コンポーネントはVuetifyをラップしたもの  ■ 【対応】使っていない機能が多いので、オリジナルのものに置き換えていくと良さそう 

Slide 24

Slide 24 text

#RAKUSMeetup  利用技術 - 辛かった点  ● テストコードがない  ○ リファクタリング時などにデグレが発生が検知できない  ■ 【対応1】テスト環境（jest）の導入  ■ 【対応2】自動テストの仕組みを作成（CI）  ○ テストを意識したコーティングになっていない  ■ Vueファイルにロジックを持ちすぎている  ■ 【対応1】helperファイルにロジックを移行  ■ 【対応2】Vue3.0への移行、ドメイン駆動思想の導入  ● Composition API 

Slide 25

Slide 25 text

これからの開発 

Slide 26

Slide 26 text

#RAKUSMeetup  振り返り作業  ● FEチームでリリースまでの開発の振り返りを行なった  ○ 先ほどの辛かった点は振り返りで出たもの（全40件ほど）  ○ 各々がスプレッドシートに改善したい項目を記載  ○ 重要度・緊急度の2軸でHigh・Middle・Lowで評価  ○ 緊急度Highから対応していく予定 

Slide 27

Slide 27 text

#RAKUSMeetup  これからの開発  ● 新規開発・改善タスクを並行で進めていく  ○ 優先度は新規開発＞改善タスク  ● FEの新規開発にかかる時間はコンポーネント化により少なくなってくる想定  ○ BEよりも工数は小さくなるはず  ○ 前倒しで進めて改善タスクを対応したい 

Slide 28

Slide 28 text

ラクスでは定期的にMeetupや  勉強会を開催しています！  ご参加お待ちしています！  ラクス   中途   フロントエンドエンジニアも募集しています。  