10年もののjQueryフロントエンドを良くしていくための道筋

あなたにとってのjQueryはなんですか？ ● キャリア黎明期を形作った技術？ ● ブラウザ間の差異を吸収してくれた福音？ ● prototype.jsからの移行に苦しめられた思い出？ ● あるいは、全く知らない過去の技術？

私にとってjQueryは青春でした

10年ものの フロントエンドを 良くしていくための道筋 菅原 政行 @plageoj

菅原 政行（@plageoj） 株式会社Faber Company (ファベルカンパニー) 新卒入社2年目 自称SRE、なんでもやります https://plageoj.me/

• 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

• https://caniuse.com/getelementsbyclassname

拡張可能なAPI $ という独自オブジェクトをグローバル名前空間にもつ → 当時流行っていた Prototype と比較して機能拡張がし やすかった → 多数のプラグインが公開されリッチなフロントエンド を作りやすくなった

• https://prototypejs.org

Ajaxインターフェースを提供 XHR jQuery

なぜ私たちは jQuery を使い続けるのか ● 自動テストがない ○ 全体に及ぶような変更を避ける必要 ● サービス全体を通して MPA である ○ ほとんどのルートがログイン必須 ○ 細かいパフォーマンスチューニングが不要 →重厚なフレームワークはいらなかった

抱えていた課題 ● どこからでもDOM操作ができ、🍝 に ● 野良のプラグインが入って管理不能に ● バンドラーが不在 ○ 読み込み順の問題 ○ グローバル変数ありすぎ問題 ○ テストができない問題

リファクタリングの方向性 1. 命名をよくする 2. Linter が活躍できる環境を作る ● グローバル変数への依存を整理する ● スタイルを統一する ● 粛々とエラーに対応する 3. コードベースを＜管理可能＞に

管理可能なコードとは ● Readable ● Reliable ● Maintainable ● Testable

命名をよくする

なぜ命名から？ ● 「良い命名」は難しいが、「明らかに悪い命名」は わかりやすい ○ スペルがおかしい ○ 命名規則に従っていない ○ 共通語彙を使っていない ……など ● 命名の変更はデグレードしにくい ● ある程度機械的に検出できる→Traceability

“supper admin” cspell を導入しエディタ拡張・CIで追跡 対応状況をトレースして進捗を説明

• https://cspell.org/

Linter が活躍できる環境を作る

グローバルありすぎ問題に立ち向かう ESLint を導入。グローバル変数を global に移動 何が入っているかを把握する → バンドラー導入後に import へ置き換えを想定

• https://eslint.org/

jQuery × ESLint ESLint の jQuery globals を使うと簡単に対応できる バージョン違いに注意！

バンドラーを入れて global を減らす Webpack を導入 ● 多数のページから呼ばれるユーティリティ関数から順 に import して使うように移行 ● ESLint の警告も減ってうれしい ● その気になれば TypeScript も使える

• https://webpack.js.org/

型チェックの導入 TypeScript を導入 ● TypeScript に書き直したくなる気持ちをこらえる ● CheckJs オプションを使う ● 型エラーはほどほどに対処する ● jQueryプラグインの型定義を自前で作る

• https://typescriptlang.org/

コードベースを管理可能にする

管理可能なコードとは ● 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操作にかかわるテストが記述できるようになった

• https://jestjs.io/ja/
• https://github.com/jsdom/jsdom

モダナイズをやりたくなったら

ツールの選定に対して考えたこと ● ピンポイントで問題を解決できるものを ● トレースができるものを ● 多少古くても文献があるものを

全部やらない vs. 全部やる 変更行数が万単位に及ぶような、超巨大な PR を 許容するか？ ● コマンド一発の機械的な変更なら、アリ ● 人間の手が入っているなら、やめたほうがいい

どうやって全員の関心にしていくか マージブロック 定期的な周知 定期的な監視 ツールの整備 ドキュメントの整備 方向性を決める

jQueryフロントエンドを良くしていくために ● ツールに指摘してもらってレベルを上げよう ● 低コストで始めて Quick win を得よう ● 根気と責任をもって改善を続けよう

プロセスやツールよりも個人と対話を コードベースの改善にはゴールも正解もない チームで語り合って行き先を決めよう ぜひ話しかけてください！ @plageoj