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

Transcript

1. 1.

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

2. 2.

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

3. 3.

   1年半前の姿 ・ ほぼすべてCoffeeScript ・ browserifyでビルド(激遅) ・ テストコードなし ・ Lint系のツールなし ・

   Vueのバージョンが0.12 ・ 重要な関数の中身が魔境 ・ jQueryどっぷりな箇所が多数
4. 4.

   現在 ・ CoffeeScript廃止 → ESNext ・ webpackでのビルド ・ Mochaでテストを書けるように ・

   ESLint導入 ・ Vueバージョン2.5に更新（最新） ・ 魔境関数を大幅リファクタリング ・ コアな機能はVue化
5. 5.

   結構大変だった

6. 6.

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

7. 7.

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

8. 8.

   人間は絶対にミスする

9. 9.

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

10. 10.

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

11. 11.

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

12. 12.

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

13. 13.

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

14. 14.

    少しずつやる

15. 15.

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

16. 16.

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

17. 17.

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

18. 18.

    段階を踏む

19. 19.

    影響範囲を小さくする

20. 20.

    広範囲に及ぶ変更は怖い

21. 21.

    であれば範囲を狭くする

22. 22.

    １画面ずつVue2.4にする e.g. Vue0.14→2.4の更新 1. Vue0.14でローカルパッケージを作る 2. 既存コードをローカルパッケージに向ける 3. Vue2.4を依存に追加 4.

    置き換えたい箇所のみ参照をVue2.4にする
23. 23.

    DOMのRead/Writeで集約 e.g. jQueryコードのリファクタリング 1. DOMのReadのみ行う部分を集約 2. DOMのWriteのみ行う部分を集約 3. DOMのRead/Write双方を行う部分を集約 4.

    DOM操作を伴わない処理に切り出し
24. 24.

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

    レビュアーの負担を軽減できる
25. 25.

    状況の可視化を怠らない

26. 26.

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

27. 27.

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

28. 28.

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

29. 29.

    テストを整える

30. 30.

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

31. 31.

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

32. 32.

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

33. 33.

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

34. 34.

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

35. 35.

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

36. 36.

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

37. 37.

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

38. 38.

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

39. 39.

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

40. 40.

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

41. 41.

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

42. 42.

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

43. 43.

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

44. 44.

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

45. 45.

    最悪の事態を想定する

46. 46.

    ユーザ影響を小さくする

47. 47.

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

48. 48.

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

49. 49.

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

50. 50.

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

51. 51.

    やっていこう！