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

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. やっていこう！