10年もののjQueryフロントエンドを良くしていくための道筋
47.8K Views
August 24, 24
スライド概要
ポケコントレーナー
関連スライド
各ページのテキスト
あなたにとってのjQueryはなんですか？ ● キャリア黎明期を形作った技術？ ● ブラウザ間の差異を吸収してくれた福音？ ● prototype.jsからの移行に苦しめられた思い出？ ● あるいは、全く知らない過去の技術？
私にとってjQueryは青春でした
10年ものの フロントエンドを 良くしていくための道筋 菅原 政行 @plageoj
菅原 政行（@plageoj） 株式会社Faber Company (ファベルカンパニー) 新卒入社2年目 自称SRE、なんでもやります https://plageoj.me/
プロダクトについて デジタルマーケティング支援SaaS B2B、内製Webサービス ● SEO（情報収集、順位監視） ● アクセス分析 Java/JSP + jQuery 2015年リリース
開発チームについて 日本4名・ベトナム20名規模で一緒に開発しています
このセッションの考え方 主張すること: ● レガシー資産を尊重する ● メンテナンス性を確保する ● 将来的な移行に耐えられるコードベースにする 主張しないこと: ● jQueryを捨てて移行する ● E2Eテストをモリモリ書いて動作を保証する
についておさらい
ブラウザ間の差異を吸収 例えば document.getElementsByClass Name もIE8までは 使えなかった jQueryではIE8でも $(".") で 要素を選択できる(1.x系まで) ref: caniuse
拡張可能なAPI $ という独自オブジェクトをグローバル名前空間にもつ → 当時流行っていた Prototype と比較して機能拡張がし やすかった → 多数のプラグインが公開されリッチなフロントエンド を作りやすくなった
Ajaxインターフェースを提供 XHR jQuery
なぜ私たちは jQuery を使い続けるのか ● 自動テストがない ○ 全体に及ぶような変更を避ける必要 ● サービス全体を通して MPA である ○ ほとんどのルートがログイン必須 ○ 細かいパフォーマンスチューニングが不要 →重厚なフレームワークはいらなかった
抱えていた課題 ● どこからでもDOM操作ができ、🍝 に ● 野良のプラグインが入って管理不能に ● バンドラーが不在 ○ 読み込み順の問題 ○ グローバル変数ありすぎ問題 ○ テストができない問題
リファクタリングの方向性 1. 命名をよくする 2. Linter が活躍できる環境を作る ● グローバル変数への依存を整理する ● スタイルを統一する ● 粛々とエラーに対応する 3. コードベースを＜管理可能＞に
管理可能なコードとは ● Readable ● Reliable ● Maintainable ● Testable
命名をよくする
なぜ命名から？ ● 「良い命名」は難しいが、「明らかに悪い命名」は わかりやすい ○ スペルがおかしい ○ 命名規則に従っていない ○ 共通語彙を使っていない ……など ● 命名の変更はデグレードしにくい ● ある程度機械的に検出できる→Traceability
“supper admin” cspell を導入しエディタ拡張・CIで追跡 対応状況をトレースして進捗を説明
Linter が活躍できる環境を作る
グローバルありすぎ問題に立ち向かう ESLint を導入。グローバル変数を global に移動 何が入っているかを把握する → バンドラー導入後に import へ置き換えを想定
jQuery × ESLint ESLint の jQuery globals を使うと簡単に対応できる バージョン違いに注意！
バンドラーを入れて global を減らす Webpack を導入 ● 多数のページから呼ばれるユーティリティ関数から順 に import して使うように移行 ● ESLint の警告も減ってうれしい ● その気になれば TypeScript も使える
型チェックの導入 TypeScript を導入 ● TypeScript に書き直したくなる気持ちをこらえる ● CheckJs オプションを使う ● 型エラーはほどほどに対処する ● jQueryプラグインの型定義を自前で作る
コードベースを管理可能にする
管理可能なコードとは ● Readable ● Reliable ● Maintainable ● Testable
取り組み順序 1. 使っていないコードは消す 2. 使っているライブラリを棚卸し 3. アップデート 4. 型情報の追加
不要コードの削減 ● 未使用機能を閉鎖する ● Unreachable なコードを削除する ● 使っていないライブラリを削除する
CDN移行 ● 直接ソースコードを置いているライブラリがあった ● npm で公開されているものは 1. CDN から読み込む 2. package.json にバージョンを記載する 3. 将来的に npm へ移行したい ● そうでないものは廃止も検討
ライブラリの管理 とにかく package.json に現行バージョンを書く ● 何のライブラリを使っているか把握する ● バージョンアップの調査を npm に任せる ● 脆弱性チェックを Dependabot に任せる
開発環境のモダナイズ
依存関係の切り離し SSR部分をフロントエンドに寄せる ● jQuery の責任が増えてきた ○ 用意された HTML の一部を書き換える役割から ページの大部分を組み立てる役割へ
DOMを宣言的っぽく組み立てる 1. DOMを一カ所で追加 2. そこまでは変数で持つ 3. 属性をオブジェクトで 与える 4. イベントハンドラは in-placeで書く
DOMを宣言的っぽく組み立てる JSPへの移行イメージ
DOMを宣言的っぽく組み立てる 気軽にXSSを埋め込めて危険 原則使わない
テストの導入 Webpack移行により、jest / jsdom によるテストを導入 DOM操作にかかわるテストが記述できるようになった
モダナイズをやりたくなったら
ツールの選定に対して考えたこと ● ピンポイントで問題を解決できるものを ● トレースができるものを ● 多少古くても文献があるものを
全部やらない vs. 全部やる 変更行数が万単位に及ぶような、超巨大な PR を 許容するか？ ● コマンド一発の機械的な変更なら、アリ ● 人間の手が入っているなら、やめたほうがいい
どうやって全員の関心にしていくか マージブロック 定期的な周知 定期的な監視 ツールの整備 ドキュメントの整備 方向性を決める
jQueryフロントエンドを良くしていくために ● ツールに指摘してもらってレベルを上げよう ● 低コストで始めて Quick win を得よう ● 根気と責任をもって改善を続けよう
プロセスやツールよりも個人と対話を コードベースの改善にはゴールも正解もない チームで語り合って行き先を決めよう ぜひ話しかけてください！ @plageoj