レガシーなフロントエンドに立ち向かう

2018/12/08 Toyama.rb #35 年末LT大会

Transcript

1. レガシーなフロントエンドに立ち向かう 2018/12/08 Toyama.rb #35 年末LT大会
2. おおよそ1年半 フロントエンドで色々やった
3. 1年半前の姿 ・ ほぼすべてCoffeeScript ・ browserifyでビルド(激遅) ・ テストコードなし ・ Lint系のツールなし ・ Vueのバージョンが0.12 ・ 重要な関数の中身が魔境 ・ jQueryどっぷりな箇所が多数
4. 現在 ・ CoffeeScript廃止 → ESNext ・ webpackでのビルド ・ Mochaでテストを書けるように ・ ESLint導入 ・ Vueバージョン2.5に更新（最新） ・ 魔境関数を大幅リファクタリング ・ コアな機能はVue化
5. 結構大変だった
6. さまざまな知見を得られた
7. ツールで出来ることはツールに任せる
8. 人間は絶対にミスする
9. 可能なものは機械に任せる
10. e.g. CoffeeScriptからの移行 decaffeinate
 https://github.com/decaffeinate/decaffeinate → ざっくりES6に変換できる
11. e.g. Vue0.14→2.4の更新 vue-migration-helper
 https://github.com/vuejs/vue-migration-helper → 影響を受ける箇所をサジェスト
12. 完璧ではない 注意！ decaffeinate → 理想のESコードにはならない vue-migration-helper → hamlは解析できない
13. 負担を軽減するために使う
14. 少しずつやる
15. 一気にやりたくなるが、こらえる
16. e.g. webpack導入時 コードの変更は基本的にしない (import/exportの書き換えのみ)
17. e.g. ESLint導入時 何段階かに分けて導入 1. eslintのインストールのみ 2. auto x可能なものを有効化 3. さらに1つずつルールを有効化
18. 段階を踏む
19. 影響範囲を小さくする
20. 広範囲に及ぶ変更は怖い
21. であれば範囲を狭くする
22. １画面ずつVue2.4にする e.g. Vue0.14→2.4の更新 1. Vue0.14でローカルパッケージを作る 2. 既存コードをローカルパッケージに向ける 3. Vue2.4を依存に追加 4. 置き換えたい箇所のみ参照をVue2.4にする
23. DOMのRead/Writeで集約 e.g. jQueryコードのリファクタリング 1. DOMのReadのみ行う部分を集約 2. DOMのWriteのみ行う部分を集約 3. DOMのRead/Write双方を行う部分を集約 4. DOM操作を伴わない処理に切り出し
24. 少しずつ or 影響を小さく進める理由 ・ トラブル発生時を考慮して - 迅速に原因特定できる - ロールバックが容易になる ・ レビュアーの負担を軽減できる
25. 状況の可視化を怠らない
26. まずはちゃんと現状を理解する
27. データフローを可視化 e.g. jQueryコードのリファクタリング
28. 必要な時間やリスクが見えてくる
29. テストを整える
30. e2eテストに命を救われる e.g. 全体的に.. ・ 「ユーザ体験」のデグレがないのを保証
31. ビジュアルテスト最高 e.g. 全体的に.. ・ 表示崩れなどを機械的に検知できる安心感
32. 足りなければ書く e.g. 全体的に.. ・ jQueryリファクタ時は
 事前に200exampleほどテストを追加
33. リファクタリング着手前に テスト整備を行う価値はある
34. レビュアーの負担を考慮する
35. リファクタPRはレビューがつらい
36. どうしても大きいPRになることもある
37. 見る側もあんまり楽しくない
38. ちゃんと説明する レビュアーの負担軽減のために ・ なんのためにやるのか？ ・ 影響範囲は？ ・ 何を確認したのか？ ・ 何を見てほしいのか？
39. テキストに頼りすぎない レビュアーの負担軽減のために ・ 時間をとって口頭で説明する ・ ペアプロ・モブプロで対応する
40. レビュアーの負担軽減のために 説明できないのであれば、 それはただの丸投げ
41. 勢い・勇気が必要なこともある
42. 粒度を小さくするコスト > 力技で対応するコスト というケースは確実に存在する 小さいほうがいいけど…
43. 時には一気にやることも必要
44. 時には一気にやることも必要 でも怖い…
45. 最悪の事態を想定する
46. ユーザ影響を小さくする
47. たとえば、リリースでの工夫はできる ・ ピークタイムを避ける ・ ロールバック手順を事前に整理する
48. リファクタリング単体では ユーザに価値は与えられない
49. だからこそ「壊さない」ことが大事
50. まとめ ・ まずは小さく進めるのが大事 ・ 泥臭い準備はつらいけど効果がある ・ 時には力技も必要になる ・ 壊さない、あるいは
 壊してもすぐ直せるようにする
51. やっていこう！