フロントエンドFW戦争を乗り越え、デザインシステムを導入した話
- 中村 芳弘
- Air事業
- AirREGI
Airシリーズのフロントエンド
- 2016年にできた
- Backboneとかもあった
- 技術スタックを揃えたい
- reactに
- エンジニアだけでは決められない
- ビジネスサイドに説明しないといけない
ビジネスサイドへの説明
- Why
- 独自FW人材確保できない
- Backbone(なぞ設計)
- 機能追加の工数大影響でかい
- How
- jsp -> spa
- 改修の入った画面から徐々に
- Backbone
- 大規模改修で一気に
- jsp -> spa
- jQueryもちょっと残ってて戦ってる
デザインシステムの導入
- 再利用可
- 自動化
プロダクトへの導入
- UXの統一
- デザイン向上
- 生産性向上
- ライブラリ
- styled-component
- storybook
効果
- これってこれでいいですかね？という確認時間をカット
- storybookでパーツごとに作ってるから共有しやすい
レガシーと向き合い技術スタックを代謝する（ElasticBeanstalk / Vue.js）
レガシーシステム
- jQueryでできてる
- jQuery + lodash.template + morphdom
- MVVM
- grunt -> gulp -> webpack
- ava, sinon, nightmareでUI差分
- codecov
- カバレッジ可視化
- sentry
- エラー即時検知
- 障害起点の調査
新規案件での取り組み
新規機能3つ追加
- 学習コスト(初動)からReactでなくVue
- Vue + vue-router
- eslint, prettier
- フォーマットの無駄な議論削減
- 仕様を決めながらだけど素早くできた
- 画面と機能の分離
- 反省点
インフラの取り組み
- jsonのモックAPIサーバ構築
- beanstalk
- node + express
- デプロイ戦略
- rolling deploy
- インスタンス使い回し
- immutable deploy
- blue/green的な?
- rolling deploy
フロントエンドのレガシー
- 非機能要件での差
- 競合他社との比較
- エンジニアとしての評価
- 社外から見た時の評価
- 古い技術
Nuxt.jsとExpressでSPA×SSR×API Aggregationを実現した話
じゃらん
- jsp
- 何十年前からあるシステム
- レガシーと新規の連携
- 負債にならないシステムを
マイクロサービス
- API Aggregationサーバ
- BFF的な?
- nuxtとexpressで
- SSRする
- expressでワンクッション
- nuxtフルスタックで便利
- 今後のPWA化もすぐできそう
- 内部でいろいろ使ってるのでデバッグでnuxtの中も見ないと・・・という点も
- SPA + SSR + API Aggregationを同じサーバにしてしまった
- 今後でかくなる懸念
- 別管理した方がいいかも
地に足をつけたフロントエンドの改善
ホットペーパービューティー
- 売上数百億開発者数百人
- 10年物の負債
- 事業は成長し続けている
- 事業側からの機能要望が多い
- デリバリー重視で負債がたまる
- 負債
- グローバル汚染によるバグ
- htmlタグ数が多すぎてレスポンス悪化
- googleカレンダーの10倍のDOM
- before
- 静的解析フォーマッタなし
- jsp
- !importが1590個
- minifyすらされてない
- 改善
- ビルドフロー整備
- minifyもする
- jenkins使う
- DOM構造のリニューアル
- 機能毎にモジュール分割
- 大規模リプレイス中
- 見た目似てるのにどう共通化するか
- デプロイサイクル
- 機能毎にモジュール分割
- ビルドフロー整備
