2018/12/08 Toyama.rb #35 年末LT大会
レガシーなフロントエンドに立ち向かう2018/12/08Toyama.rb #35 年末LT大会
View Slide
おおよそ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になることもある
見る側もあんまり楽しくない
ちゃんと説明するレビュアーの負担軽減のために・ なんのためにやるのか?・ 影響範囲は?・ 何を確認したのか?・ 何を見てほしいのか?
テキストに頼りすぎないレビュアーの負担軽減のために・ 時間をとって口頭で説明する・ ペアプロ・モブプロで対応する
レビュアーの負担軽減のために説明できないのであれば、それはただの丸投げ
勢い・勇気が必要なこともある
粒度を小さくするコスト>力技で対応するコストというケースは確実に存在する小さいほうがいいけど…
時には一気にやることも必要
時には一気にやることも必要でも怖い…
最悪の事態を想定する
ユーザ影響を小さくする
たとえば、リリースでの工夫はできる・ ピークタイムを避ける・ ロールバック手順を事前に整理する
リファクタリング単体ではユーザに価値は与えられない
だからこそ「壊さない」ことが大事
まとめ・ まずは小さく進めるのが大事・ 泥臭い準備はつらいけど効果がある・ 時には力技も必要になる・ 壊さない、あるいは 壊してもすぐ直せるようにする
やっていこう!