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
レガシーなフロントエンドに立ち向かう
Search
Hajime Mugishima
December 08, 2018
Technology
1
620
レガシーなフロントエンドに立ち向かう
2018/12/08 Toyama.rb #35 年末LT大会
Hajime Mugishima
December 08, 2018
Tweet
Share
More Decks by Hajime Mugishima
See All by Hajime Mugishima
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
13
6.9k
New Order in Cascade Sorting Order
mugi_uno
3
3.6k
Deep Dive into React Stream/Serialize
mugi_uno
8
2.1k
Next.js App Router での MPA フロントエンド刷新
mugi_uno
41
24k
コロナ禍 Frontend おさらい
mugi_uno
1
450
Toyama.rb
mugi_uno
1
140
kintoneフロントエンド刷新 〜新規参加5ヶ月から見るリアル〜
mugi_uno
3
1.8k
Javaを富山でやってたはずがSwiftのためにMacBook買ったらRubyでリモートワーカーになってJSの本を出版するまでを思い返す
mugi_uno
7
2.6k
脱レガシーフロントエンドのために知っておいたほうがいいこと
mugi_uno
20
7.5k
Other Decks in Technology
See All in Technology
「どこにある?」の解決。生成AI(RAG)で効率化するガバメントクラウド運用
toru_kubota
2
420
QAはソフトウェアエンジニアリングを学んで実践するのが大事なの
ymty
1
400
技術職じゃない私がVibe Codingで感じた、AGIが身近になる未来
blueb
0
130
「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの 考え方・育て方 / Cursor Rules for Coding Styles, Domain Knowledges and Operations
yuitosato
6
1.7k
データ戦略部門 紹介資料
sansan33
PRO
1
3.2k
AI技術トレンド勉強会 #1MCPの基礎と実務での応用
nisei_k
1
200
IIWレポートからみるID業界で話題のMCP
fujie
0
340
Definition of Done
kawaguti
PRO
2
110
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.6k
上長や社内ステークホルダーに対する解像度を上げて、より良い補完関係を築く方法 / How-to-increase-resolution-and-build-better-complementary-relationships-with-your-bosses-and-internal-stakeholders
madoxten
13
7.7k
Whats_new_in_Podman_and_CRI-O_2025-06
orimanabu
3
180
kubellが挑むBPaaSにおける、人とAIエージェントによるサービス開発の最前線と技術展望
kubell_hr
1
310
Featured
See All Featured
Being A Developer After 40
akosma
90
590k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Faster Mobile Websites
deanohume
307
31k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
How STYLIGHT went responsive
nonsquared
100
5.6k
How to Ace a Technical Interview
jacobian
276
23k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Rails Girls Zürich Keynote
gr2m
94
14k
Transcript
レガシーなフロントエンドに立ち向かう 2018/12/08 Toyama.rb #35 年末LT大会
おおよそ1年半 フロントエンドで色々やった
1年半前の姿 ・ ほぼすべてCoffeeScript ・ browserifyでビルド(激遅) ・ テストコードなし ・ Lint系のツールなし ・
Vueのバージョンが0.12 ・ 重要な関数の中身が魔境 ・ jQueryどっぷりな箇所が多数
現在 ・ CoffeeScript廃止 → ESNext ・ webpackでのビルド ・ Mochaでテストを書けるように ・
ESLint導入 ・ Vueバージョン2.5に更新(最新) ・ 魔境関数を大幅リファクタリング ・ コアな機能はVue化
結構大変だった
さまざまな知見を得られた
ツールで出来ることはツールに任せる
人間は絶対にミスする
可能なものは機械に任せる
e.g. CoffeeScriptからの移行 decaffeinate https://github.com/decaffeinate/decaffeinate → ざっくりES6に変換できる
e.g. Vue0.14→2.4の更新 vue-migration-helper https://github.com/vuejs/vue-migration-helper → 影響を受ける箇所をサジェスト
完璧ではない 注意! decaffeinate → 理想のESコードにはならない vue-migration-helper → hamlは解析できない
負担を軽減するために使う
少しずつやる
一気にやりたくなるが、こらえる
e.g. webpack導入時 コードの変更は基本的にしない (import/exportの書き換えのみ)
e.g. ESLint導入時 何段階かに分けて導入 1. eslintのインストールのみ 2. auto x可能なものを有効化 3. さらに1つずつルールを有効化
段階を踏む
影響範囲を小さくする
広範囲に及ぶ変更は怖い
であれば範囲を狭くする
1画面ずつVue2.4にする e.g. Vue0.14→2.4の更新 1. Vue0.14でローカルパッケージを作る 2. 既存コードをローカルパッケージに向ける 3. Vue2.4を依存に追加 4.
置き換えたい箇所のみ参照をVue2.4にする
DOMのRead/Writeで集約 e.g. jQueryコードのリファクタリング 1. DOMのReadのみ行う部分を集約 2. DOMのWriteのみ行う部分を集約 3. DOMのRead/Write双方を行う部分を集約 4.
DOM操作を伴わない処理に切り出し
少しずつ or 影響を小さく進める理由 ・ トラブル発生時を考慮して - 迅速に原因特定できる - ロールバックが容易になる ・
レビュアーの負担を軽減できる
状況の可視化を怠らない
まずはちゃんと現状を理解する
データフローを可視化 e.g. jQueryコードのリファクタリング
必要な時間やリスクが見えてくる
テストを整える
e2eテストに命を救われる e.g. 全体的に.. ・ 「ユーザ体験」のデグレがないのを保証
ビジュアルテスト最高 e.g. 全体的に.. ・ 表示崩れなどを機械的に検知できる安心感
足りなければ書く e.g. 全体的に.. ・ jQueryリファクタ時は 事前に200exampleほどテストを追加
リファクタリング着手前に テスト整備を行う価値はある
レビュアーの負担を考慮する
リファクタPRはレビューがつらい
どうしても大きいPRになることもある
見る側もあんまり楽しくない
ちゃんと説明する レビュアーの負担軽減のために ・ なんのためにやるのか? ・ 影響範囲は? ・ 何を確認したのか? ・ 何を見てほしいのか?
テキストに頼りすぎない レビュアーの負担軽減のために ・ 時間をとって口頭で説明する ・ ペアプロ・モブプロで対応する
レビュアーの負担軽減のために 説明できないのであれば、 それはただの丸投げ
勢い・勇気が必要なこともある
粒度を小さくするコスト > 力技で対応するコスト というケースは確実に存在する 小さいほうがいいけど…
時には一気にやることも必要
時には一気にやることも必要 でも怖い…
最悪の事態を想定する
ユーザ影響を小さくする
たとえば、リリースでの工夫はできる ・ ピークタイムを避ける ・ ロールバック手順を事前に整理する
リファクタリング単体では ユーザに価値は与えられない
だからこそ「壊さない」ことが大事
まとめ ・ まずは小さく進めるのが大事 ・ 泥臭い準備はつらいけど効果がある ・ 時には力技も必要になる ・ 壊さない、あるいは 壊してもすぐ直せるようにする
やっていこう!