Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AndAppのフロントエンド事情
Search
emahiro
February 19, 2019
Programming
0
970
AndAppのフロントエンド事情
https://www.andapp.jp
で使われてるフロントエンドの技術的変遷のお話。
emahiro
February 19, 2019
Tweet
Share
More Decks by emahiro
See All by emahiro
事業を止めない技術改善の取り組み
emahiro
0
2.9k
Go_Conference_2019_Spring_Go1.9_to_Go1.11.pdf
emahiro
2
13k
Other Decks in Programming
See All in Programming
Protocol Buffersの型を超えて拡張性を得る / Beyond Protocol Buffers Types Achieving Extensibility
linyows
0
100
Kiroで始めるAI-DLC
kaonash
2
510
Namespace and Its Future
tagomoris
6
690
ECS初心者の仲間 – TUIツール「e1s」の紹介
keidarcy
0
150
ソフトウェアテスト徹底指南書の紹介
goyoki
1
130
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
Honoアップデート 2025年夏
yusukebe
1
900
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
150
Claude Codeで実装以外の開発フロー、どこまで自動化できるか?失敗と成功
ndadayo
4
1.8k
Improving my own Ruby thereafter
sisshiki1969
1
150
AIレビュアーをスケールさせるには / Scaling AI Reviewers
technuma
2
240
tool ディレクティブを導入してみた感想
sgash708
1
160
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
The Invisible Side of Design
smashingmag
301
51k
Why Our Code Smells
bkeepers
PRO
339
57k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
284
13k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
185
54k
Transcript
AndAppのフロントエンド事情 ~SPA化からTypeScriptの導入まで~ 2019.02.19 hiromichi ema
自己紹介 name: 江間啓道 (Hiromichi Ema) twitter: @ema_hiro DeNA歴: 2年と4ヶ月くらい (キュレーション半年
-> OPF: 1年半ちょっと) job: AndAppのサーバーサイド/フロントエンドを担当し てます。 趣味: サッカー観戦、フットサル、カメラ
AndAppとは?
スマホゲームをPCでできるプラットフォーム • スマホとPCでアカウントを同期できる。 • AndAppポイントやツールなどの「捗る」をサポートする便利機能多数。 • 興味がある方はぜひ -> https://www.andapp.jp にアクセスしてPCアプリをDLしてみ
てください。
本日話すこと • AndAppクライアントのSPA化 • AndAppクライアントのフロントエンドへのTypeScriptの導入について ※ この発表における「AndAppクライアント」とはユーザー向けに提供されてる UI部分を指します。
本日話すこと • AndAppクライアントのSPA化 • AndAppクライアントのフロントエンドへのTypeScriptの導入について ※ この発表における「AndAppクライアント」とはユーザー向けに提供されてる UI部分を指します。
AndAppクライアントのSPA化
背景 • AndAppクライアントのUI部分はelectronのwebviewで実装されている。 • AndAppクライアントのタブを遷移ごとにこのwebviewの再読み込みがかかってペー ジの表示に時間がかかっていた。 => ちょうどその頃AndAppクライアントの機能を再定義して、UIを刷新するというプロジェクトが立 ち上がった。
AndAppクライアントリニューアルプロジェクト発足 • 2017年夏ごろから足掛け1年半くらいかけてのAndAppクライアントのUIリニューアルプ ロジェクト (2017年夏にスタートし、最終的なリリースは2018年12月) • UIを刷新するならせっかくなのでUI部分をSPA化して、タブ遷移時のユーザー体験を 改善させることに。
リニューアル Phase1 - 2 リスティング機能、通知周りのUI刷新
Phase1~2でやったこと • Vue.jsを採用してSPAとして再実装。 • 対象はTOP・詳細・カテゴリ・通知一覧の画面。
なぜ、Vue.jsを採用したのか?
なぜ Vue.js? AndAppで使用実績がすでにあったから! • フロントエンドエンジニアが馴染んでいたこと。 • VueのSFC(Single File Component)が書きやすかったこと。 •
技術統一的な観点。
開発の仕方 1. Interfaceを決める。 2. サーバーからInterfaceに沿った素のjsonファイルを返すだけのEndpointを先んじて実 装し、バックエンドとフロントエンドそれぞれでパラレルで開発。 3. 出来上がったEndpointからダミーと本番を差し替える。 ※ ありがちなパターンでAndAppプロジェクトに限った話はなし。
SPA化の効果 • 読み込みは初回だけ時間がかかるが導入前に比べると改善された。 • 問題だったタブ間遷移はサクサク動くように! • フロントエンドのスキルスタックとしてSPAが追加され、少しだけモダンな開発環境に なった。
Phase1~2の課題 • APIとのつなぎこみやQA検証段階で見つかるバグがめちゃくちゃ多かった。 ◦ しかも意図しない型違いや、undefinedエラーなど初歩的なエラーがポコポコ出て きてしまった。 • その結果、UI側の検証項目(QCの項目)に対するバグ修正がめちゃくちゃ多くてフロン トエンジニアが帰れなくなった。
本日話すこと • AndAppクライアントのSPA化 • AndAppクライアントのフロントエンドへのTypeScriptの導入について ※ この発表における「AndAppクライアント」とはユーザー向けに提供されてる UI部分を指します。
TypeScriptの導入
背景 • クライアントリニューアルプロジェクトの各段階は独立しており、phase1、2の課題点を phase3に持ち越したくなかった。 • phase3は仕様としてもかなり大きく、このまま行くと検証がめっちゃ大変になりそうって いうことをなんとなく開発してるチーム内で感じていた。 • 再び帰れなくなる日々が待ってるかも知れなかった。
リニューアルPhase3 ライブラリタブとツールタブの追加 (画像はライブラリタブのものです)
Phase3でやったこと • TypeScriptの導入 ◦ SFC以外では全面的に採用 • 一部UnitTestの導入 ◦ テストには「jest」を採用
なぜ、TypeScriptを採用したのか?
なぜ TypeScriptか? その1 Phase1~2の時の課題のおさらい • 検証段階になってバグがめちゃくちゃでる • UI側のバグ修正ががめちゃくちゃ出てフロントエンドの工数が肥大化する。 この課題へのアプローチとして •
実装段階で静的にチェックしてくれる機構が欲しくなった。 => 実装時に検出できる不具合や凡ミスはできるだけ実装時に気づきたい。
なぜ TypeScriptか? その2 当初候補は2つあった • TypeScript • Flow TypeScriptに決めた理由 •
トランスパイルした結果、 中間ファイルとしてjsが出力されるので捨てやすそうという期待。 • TypeScriptがフロントエンドの流れ的に主流派になりそう な雰囲気があった。
マイグレーション方法 1. TypeScriptのルールを決める 2. 既存のES6のファイルを愚直にTypeScriptに書き換える 3. 新機能は最初からTypeScriptで実装
TypeScriptのルールを決める 1. tsconfigでどのルールを採用するかを検討。 a. noImplicitAny: true まで含めて採用 cf. https://www.typescriptlang.org/docs/handbook/tsconfig-json.html 2.
tslintのルールも並行して決定。 a. tslint:latest に準拠
既存のES6のファイルを愚直にTypeScriptに書き換える 1. *.js -> *.ts に変更 2. コンパイルエラー解消 3. ファイル単位で相互にレビュー
新機能は最初からTypeScriptで実装 先にTypeScriptに慣れていたので、特に問題なく進められた。
TypeScript導入の効果 その1 効果があったこと • 実装時に防げるミスを実装時に寄せることができた。 • 開発者体験の向上
TypeScript導入の効果 その2 効果がなかったこと • 最終的なバグ、開発工数の減少には効果があまりなかった。 • Phase3から一部ユニットテストを導入したが、ロジックのミス、開発工数の削減につい てはこちらの方が効果があった。
その他 • phase3の時からwebpack-dev-serverでlocalにserverを立ててレスポンスをmockに 差し替えるという開発手法に変更。 • Vuexに型をつけるという作業が結構手間取った。
まとめ
まとめ • AndAppクライアントのフロントエンドは足掛け1年くらいかけてぼちぼちモダンな技術スタッ クになっていること。 • リファクタリング(TypeScript化)と機能追加(ライブラリ/ツールの追加)は一緒に行ってはい けない。というあたり前のことに気付かされたこと。 • 今後の野望 ◦
三重管理されているInterface定義をどうにかする。 ◦ 別ウェブページとしてサーブされてるポイント機能を同じSPA上に乗せる & TypeScript 化 ◦ Vue3.0にあげる(夏過ぎくらいに出るらしい)
ご静聴ありがとうございました ご意見ご質問等ありましたらお気軽に #times-emahiro まで