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
mugi / Hajime Mugishima
December 08, 2018
Technology
1
630
レガシーなフロントエンドに立ち向かう
2018/12/08 Toyama.rb #35 年末LT大会
mugi / Hajime Mugishima
December 08, 2018
Tweet
Share
More Decks by mugi / Hajime Mugishima
See All by mugi / Hajime Mugishima
サイボウズフロントエンドの横断活動から考える AI時代にできること
mugi_uno
4
1.6k
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
13
7k
New Order in Cascade Sorting Order
mugi_uno
3
3.8k
Deep Dive into React Stream/Serialize
mugi_uno
8
2.1k
Next.js App Router での MPA フロントエンド刷新
mugi_uno
41
24k
コロナ禍 Frontend おさらい
mugi_uno
1
460
Toyama.rb
mugi_uno
1
150
kintoneフロントエンド刷新 〜新規参加5ヶ月から見るリアル〜
mugi_uno
3
1.8k
Javaを富山でやってたはずがSwiftのためにMacBook買ったらRubyでリモートワーカーになってJSの本を出版するまでを思い返す
mugi_uno
7
2.6k
Other Decks in Technology
See All in Technology
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
3
200
20250913_JAWS_sysad_kobe
takuyay0ne
2
250
LLM時代のパフォーマンスチューニング:MongoDB運用で試したコンテキスト活用の工夫
ishikawa_pro
0
170
LLMを搭載したプロダクトの品質保証の模索と学び
qa
1
1.1k
Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform
pei0804
1
200
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
990
20250905_MeetUp_Ito-san_s_presentation.pdf
magicpod
1
100
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
1
240
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
890
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい勘所を集めてみました! - / How to start Scrum that is not written in the Scrum Guide 2nd
takaking22
2
220
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1.2k
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
Featured
See All Featured
Balancing Empowerment & Direction
lara
3
630
Facilitating Awesome Meetings
lara
55
6.5k
BBQ
matthewcrist
89
9.8k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
590
Music & Morning Musume
bryan
46
6.8k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
How GitHub (no longer) Works
holman
315
140k
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になることもある
見る側もあんまり楽しくない
ちゃんと説明する レビュアーの負担軽減のために ・ なんのためにやるのか? ・ 影響範囲は? ・ 何を確認したのか? ・ 何を見てほしいのか?
テキストに頼りすぎない レビュアーの負担軽減のために ・ 時間をとって口頭で説明する ・ ペアプロ・モブプロで対応する
レビュアーの負担軽減のために 説明できないのであれば、 それはただの丸投げ
勢い・勇気が必要なこともある
粒度を小さくするコスト > 力技で対応するコスト というケースは確実に存在する 小さいほうがいいけど…
時には一気にやることも必要
時には一気にやることも必要 でも怖い…
最悪の事態を想定する
ユーザ影響を小さくする
たとえば、リリースでの工夫はできる ・ ピークタイムを避ける ・ ロールバック手順を事前に整理する
リファクタリング単体では ユーザに価値は与えられない
だからこそ「壊さない」ことが大事
まとめ ・ まずは小さく進めるのが大事 ・ 泥臭い準備はつらいけど効果がある ・ 時には力技も必要になる ・ 壊さない、あるいは 壊してもすぐ直せるようにする
やっていこう!