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

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

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

0f162107f1b716c9fa62d6071eb8b995?s=128

Hajime Mugishima

December 08, 2018
Tweet

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. 1画面ずつ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. やっていこう!