Tweet
Tweet

Slide 1

Slide 1 text

レガシーなフロントエンドに立ち向かう 2018/12/08 Toyama.rb #35 年末LT大会

Slide 2

Slide 2 text

おおよそ1年半 フロントエンドで色々やった

Slide 3

Slide 3 text

1年半前の姿 ・ ほぼすべてCoffeeScript ・ browserifyでビルド(激遅) ・ テストコードなし ・ Lint系のツールなし ・ Vueのバージョンが0.12 ・ 重要な関数の中身が魔境 ・ jQueryどっぷりな箇所が多数

Slide 4

Slide 4 text

現在 ・ CoffeeScript廃止 → ESNext ・ webpackでのビルド ・ Mochaでテストを書けるように ・ ESLint導入 ・ Vueバージョン2.5に更新（最新） ・ 魔境関数を大幅リファクタリング ・ コアな機能はVue化

Slide 5

Slide 5 text

結構大変だった

Slide 6

Slide 6 text

さまざまな知見を得られた

Slide 7

Slide 7 text

ツールで出来ることはツールに任せる

Slide 8

Slide 8 text

人間は絶対にミスする

Slide 9

Slide 9 text

可能なものは機械に任せる

Slide 10

Slide 10 text

e.g. CoffeeScriptからの移行 decaffeinate
 https://github.com/decaffeinate/decaffeinate → ざっくりES6に変換できる

Slide 11

Slide 11 text

e.g. Vue0.14→2.4の更新 vue-migration-helper
 https://github.com/vuejs/vue-migration-helper → 影響を受ける箇所をサジェスト

Slide 12

Slide 12 text

完璧ではない 注意！ decaffeinate → 理想のESコードにはならない vue-migration-helper → hamlは解析できない

Slide 13

Slide 13 text

負担を軽減するために使う

Slide 14

Slide 14 text

少しずつやる

Slide 15

Slide 15 text

一気にやりたくなるが、こらえる

Slide 16

Slide 16 text

e.g. webpack導入時 コードの変更は基本的にしない (import/exportの書き換えのみ)

Slide 17

Slide 17 text

e.g. ESLint導入時 何段階かに分けて導入 1. eslintのインストールのみ 2. auto x可能なものを有効化 3. さらに1つずつルールを有効化

Slide 18

Slide 18 text

段階を踏む

Slide 19

Slide 19 text

影響範囲を小さくする

Slide 20

Slide 20 text

広範囲に及ぶ変更は怖い

Slide 21

Slide 21 text

であれば範囲を狭くする

Slide 22

Slide 22 text

１画面ずつVue2.4にする e.g. Vue0.14→2.4の更新 1. Vue0.14でローカルパッケージを作る 2. 既存コードをローカルパッケージに向ける 3. Vue2.4を依存に追加 4. 置き換えたい箇所のみ参照をVue2.4にする

Slide 23

Slide 23 text

DOMのRead/Writeで集約 e.g. jQueryコードのリファクタリング 1. DOMのReadのみ行う部分を集約 2. DOMのWriteのみ行う部分を集約 3. DOMのRead/Write双方を行う部分を集約 4. DOM操作を伴わない処理に切り出し

Slide 24

Slide 24 text

少しずつ or 影響を小さく進める理由 ・ トラブル発生時を考慮して - 迅速に原因特定できる - ロールバックが容易になる ・ レビュアーの負担を軽減できる

Slide 25

Slide 25 text

状況の可視化を怠らない

Slide 26

Slide 26 text

まずはちゃんと現状を理解する

Slide 27

Slide 27 text

データフローを可視化 e.g. jQueryコードのリファクタリング

Slide 28

Slide 28 text

必要な時間やリスクが見えてくる

Slide 29

Slide 29 text

テストを整える

Slide 30

Slide 30 text

e2eテストに命を救われる e.g. 全体的に.. ・ 「ユーザ体験」のデグレがないのを保証

Slide 31

Slide 31 text

ビジュアルテスト最高 e.g. 全体的に.. ・ 表示崩れなどを機械的に検知できる安心感

Slide 32

Slide 32 text

足りなければ書く e.g. 全体的に.. ・ jQueryリファクタ時は
 事前に200exampleほどテストを追加

Slide 33

Slide 33 text

リファクタリング着手前に テスト整備を行う価値はある

Slide 34

Slide 34 text

レビュアーの負担を考慮する

Slide 35

Slide 35 text

リファクタPRはレビューがつらい

Slide 36

Slide 36 text

どうしても大きいPRになることもある

Slide 37

Slide 37 text

見る側もあんまり楽しくない

Slide 38

Slide 38 text

ちゃんと説明する レビュアーの負担軽減のために ・ なんのためにやるのか？ ・ 影響範囲は？ ・ 何を確認したのか？ ・ 何を見てほしいのか？

Slide 39

Slide 39 text

テキストに頼りすぎない レビュアーの負担軽減のために ・ 時間をとって口頭で説明する ・ ペアプロ・モブプロで対応する

Slide 40

Slide 40 text

レビュアーの負担軽減のために 説明できないのであれば、 それはただの丸投げ

Slide 41

Slide 41 text

勢い・勇気が必要なこともある

Slide 42

Slide 42 text

粒度を小さくするコスト > 力技で対応するコスト というケースは確実に存在する 小さいほうがいいけど…

Slide 43

Slide 43 text

時には一気にやることも必要

Slide 44

Slide 44 text

時には一気にやることも必要 でも怖い…

Slide 45

Slide 45 text

最悪の事態を想定する

Slide 46

Slide 46 text

ユーザ影響を小さくする

Slide 47

Slide 47 text

たとえば、リリースでの工夫はできる ・ ピークタイムを避ける ・ ロールバック手順を事前に整理する

Slide 48

Slide 48 text

リファクタリング単体では ユーザに価値は与えられない

Slide 49

Slide 49 text

だからこそ「壊さない」ことが大事

Slide 50

Slide 50 text

まとめ ・ まずは小さく進めるのが大事 ・ 泥臭い準備はつらいけど効果がある ・ 時には力技も必要になる ・ 壊さない、あるいは
 壊してもすぐ直せるようにする

Slide 51

Slide 51 text

やっていこう！