Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Hajime Mugishima

December 08, 2018
Tweet

More Decks by Hajime Mugishima

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. 結構大変だった

    View Slide

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

    View Slide

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

    View Slide

  8. 人間は絶対にミスする

    View Slide

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

    View Slide

  10. e.g. CoffeeScriptからの移行
    decaffeinate

    https://github.com/decaffeinate/decaffeinate
    → ざっくりES6に変換できる

    View Slide

  11. e.g. Vue0.14→2.4の更新
    vue-migration-helper

    https://github.com/vuejs/vue-migration-helper
    → 影響を受ける箇所をサジェスト

    View Slide

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

    View Slide

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

    View Slide

  14. 少しずつやる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. 段階を踏む

    View Slide

  19. 影響範囲を小さくする

    View Slide

  20. 広範囲に及ぶ変更は怖い

    View Slide

  21. であれば範囲を狭くする

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. 状況の可視化を怠らない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. テストを整える

    View Slide

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

    View Slide

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

    View Slide

  32. 足りなければ書く
    e.g. 全体的に..
    ・ jQueryリファクタ時は

    事前に200exampleほどテストを追加

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. 最悪の事態を想定する

    View Slide

  46. ユーザ影響を小さくする

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. まとめ
    ・ まずは小さく進めるのが大事
    ・ 泥臭い準備はつらいけど効果がある
    ・ 時には力技も必要になる
    ・ 壊さない、あるいは

    壊してもすぐ直せるようにする

    View Slide

  51. やっていこう!

    View Slide