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
870
AndAppのフロントエンド事情
https://www.andapp.jp
で使われてるフロントエンドの技術的変遷のお話。
emahiro
February 19, 2019
Tweet
Share
More Decks by emahiro
See All by emahiro
事業を止めない技術改善の取り組み
emahiro
0
2.7k
Go_Conference_2019_Spring_Go1.9_to_Go1.11.pdf
emahiro
2
12k
Other Decks in Programming
See All in Programming
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
.NET のための通信フレームワーク MagicOnion 入門 / Introduction to MagicOnion
mayuki
1
1.4k
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night
junk0612
5
2.1k
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
8
540
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
190
Jakarta EE meets AI
ivargrimstad
0
530
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
Contemporary Test Cases
maaretp
0
130
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.3k
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
110
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
6
1.7k
距離関数を極める! / SESSIONS 2024
gam0022
0
280
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
97
11k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Faster Mobile Websites
deanohume
305
30k
Scaling GitHub
holman
458
140k
For a Future-Friendly Web
brad_frost
175
9.4k
4 Signs Your Business is Dying
shpigford
180
21k
Speed Design
sergeychernyshev
24
610
A Philosophy of Restraint
colly
203
16k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
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 まで