地に足をつけたフロントエンドの改善

地に足をつけたフロントエンドの改善

1. 1. 地に足をつけた フロントエンドの改善 RLS Meetup#9 リクルートライフスタイルのフロントエンドのいまとこれから May 24, 2018 @inureo
2. 2. Ryo Tezuka @inureo 来歴 ❑ 2009年04月 デザイナーとしてWeb制作会社に入社 ❑ 2013年10月 エンジニアとしてnanapiに入社 ❑ 2015年09月 リクルートライフスタイルに入社 ❑ 新規事業開発チームで開発責任者担当 ❑ 美容事業配属後、カスタマサポートや事業部を巻 き込んだ生産性向上プロジェクトの立ち上げ ❑ 現在リプレイスプロジェクト担当
3. 3. ホットペッパービューティーとは 国内最大級のヘアサロン リラク&ビューティーサロン検索予約サイト
4. 4. 今日話すこと・話(さ|せ)ないこと ❑ 話すこと ❑ 大規模な事業・組織で仕事する上での観点 ❑ 改善をなぜやるか/どうやるか/なにをやるか ❑ 話(さ|せ)ないこと ❑ 具体的な技術のこと ❑ 改善にどういう効果があったか
5. 5. 早速ですが
6. 6. 美容事業領域 フロントエンド イケてないです
7. 7. グローバル汚染 common.cssと global.cssの共存 minifyされていないコード 異なるバージョンの jQueryが共存 /DEVから始まる 謎のパス 内部仕様が 記載されたコメント 最適化されていない 大量の画像ボタン 中途半端な sprite image 納品されたHTML/CSSを エンジニアがマージするフロー HTML4 懐かしのShift-JIS DOMとJSの密結合 HTML/CSSの 密結合
8. 8. グローバル汚染 common.cssと global.cssの共存 minifyされていないコード 異なるバージョンの jQueryが共存 /DEVから始まる 謎のパス 内部仕様が 記載されたコメント 最適化されていない 大量の画像ボタン 中途半端な sprite image 納品されたHTML/CSSを エンジニアがマージするフロー HTML4 懐かしのShift-JIS DOMとJSが密結合 HTML/CSSも 密結合 10年もの負債
9. 9. しかし事業は成長し続けている 株式会社リクルートホールディングス 2018年03月期 決算資料より引用 ❑ 事業成長が著しいため、機能開発要望がどんどんでる ❑ なんとか早くリリースしたい企画者 ❑ それを叶えようとしつづけた開発者 ❑ みんなが事業成長のために開発をした結果、、
10. 10. Quality Cost Delivery ❑ Delivery優先で負債が残るような形での開発 ❑ 負債を返済する間もなく、次の機能開発へ ❑ このままだと負債により開発速度が鈍化してしまう Delivery > Quality
11. 11. ❑ アプリ・Webアプリケーションリプレイスや 開発業務プロセスを改善する基盤チームなど 様々なプロジェクトが進行中 … 続く成長を見越し、負債の解消が必要
12. 12. フロントエンドも負債が表面化 ❑ Extensionの影響で予期せぬ挙動 ❑ とある案件でHTMLタグ数がボトルネック となりブラウザのレンダリング時間が増加。 リフロー・リペイントが重すぎて操作が難 しくなり、QA前に急遽リファクタリングが 必要となったり…
13. 13. フロントエンドも負債が表面化 IE Chrome Safari Firefox 改善前 4,300ms 1,400ms 2,600ms 2,400ms 改善後 1,200ms 630ms 1,200ms 1,000ms ❑ Extensionの影響で予期せぬ挙動 (RequireJS起因) ❑ HTMLタグ数がボトルネックとなりブラウザの レンダリング時間増加、リフロー・リペイント が重すぎて操作が不可能な状況 => 急遽リファクタリングが必要となった 改善前 改善後 Google Calendar HTMLタグ数 9,432個 2,343個 1,135個 フロントエンドも 改善せねば…
14. 14. フロントエンドの改善 ❑ なぜやるのか
15. 15. フロントエンドの改善 ❑ なぜやるのか ❑ 更なる事業成長を実現するため
16. 16. フロントエンドの改善 ❑ なぜやるのか ❑ 更なる事業成長を実現するため ❑ どうやるのか
17. 17. フロントエンドの改善 ❑ なぜやるのか ❑ 更なる事業成長を実現するため ❑ どうやるのか ❑ コーディングルール/ガイドラインを整備して コード品質を安定化 ❑ 新しい技術の恩恵を受けられる ❑ 保守・運用・拡張しやすいコード
18. 18. フロントエンドの現状 ❑ コーディングルール/ガイドラインを整備して コード品質を安定化 ❑ 特にルールのない無秩序なコード ❑ 静的解析ツールやフォーマッタを使っていない ❑ 新しい技術の恩恵を受けられる ❑ ES5、生CSS、jspテンプレートの運用 ❑ トランスパイル以前にminifyすらされていない ❑ 保守・運用・拡張しやすいコード ❑ CSS内に!importantが1,590個存在している リプレイスを進めているアプリケーションではあてはまらないものもあります
19. 19. 改善するためになにをやるのか
20. 20. 改善するためになにをやるのか ❑ minifyと静的コンテンツリリースのJob化 ❑ JS/CSSのｍinify対応 ❑ 静的コンテンツリリースをJob化する ❑ DOM構造リニューアルの設計 ❑ コンポーネント設計・実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計
21. 21. 改善するためになにをやるのか ❑ minifyと静的コンテンツリリースのJob化 ❑ JS/CSSのｍinify対応 ❑ 静的コンテンツリリースをJob化する ❑ DOM構造リニューアルの設計 ❑ コンポーネント設計・実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計 ビルドフローを整備し 後々手を加えやすく 現状、静的解析や 品質管理が難しい ので整備する
22. 22. ただハレーションが起きるので地道に ❑ minifyと静的コンテンツリリースのJob化 ❑ JS/CSSのｍinify対応 ❑ 静的コンテンツリリースをJob化する ❑ DOM構造リニューアルの設計 ❑ コンポーネント設計・実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計 コンポーネント化したとして、 プロダクトの装着はどうする？ コンポーネントが更新された時の 影響・反映フローは？ 既存フローの変更影響は？ minifyすることでNewRelic BrowserでのJS Error検知が できなくなるが？
23. 23. 技術的難度より仕事難度が高い 事業規模小 サービス レベル低い 事業規模大 サービス レベル高い ホットペッパー ビューティー ❑ 数百億の売上をあげて いるため要求されるサー ビスレベルが高い ❑ 数百人規模の開発組織 なので運用を変えるハー ドルが高い 数百億の売上 開発者だけで百数十人
24. 24. 技術的難度より仕事難度が高い 事業規模小 サービス レベル低い 事業規模大 サービス レベル高い ホットペッパー ビューティー 数百億の売上 開発者だけで百数十人 ❑ 数百億の売上をあげて いるため要求されるサー ビスレベルが高い ❑ 数百人規模の開発組織 なので運用を変えるハー ドルが高い ＿人人人人人人人人人人人＿ ＞　大規模ゆえの難しさ　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
25. 25. minifyと静的コンテンツリリースのJob化
26. 26. minifyと静的コンテンツリリースのJob化 開発T GhE Webサーバ 👉👉👉👉 👉👉 3.rsync プライベートクラウド As-Is 2.git pull1.git push 作業サーバ 運用Tが作業用サーバに ログインして手作業でリリース
27. 27. minifyと静的コンテンツリリースのJob化 開発T GhE Webサーバ 👉👉👉👉 👉👉 3.rsync プライベートクラウド 2.git pull1.git push As-Is 運用Tが作業用サーバに ログインして手作業でリリース 作業サーバ RHEL5(現状) Java6
28. 28. 開発T GhE 作業サーバ Webサーバ 👉👉👉👉 👉👉 3.rsync プライベートクラウド 開発T GhE Jenkinsサーバ Webサーバ 👉👉👉👉 👉👉 プライベートクラウド 2.git pull1.git push 1.git push 2.git pull 3.minify ( Java6で ) 5.rsync minifyと静的コンテンツリリースのJob化 As-Is To-Be 開発者 Jobﾎﾟﾁｰ 運用Tが作業用サーバに ログインして手作業でリリース RHEL5(現状) Java6
29. 29. 開発T GhE Webサーバ 👉👉👉👉 👉👉 3.rsync2.git pull1.git push プライベートクラウド 開発T GhE Webサーバ 👉👉👉👉 👉👉 1.git push プライベートクラウド 2.git pull 4. source map 紐付け To-Be minifyされたコードで エラーを追うため 3.minify ( Java6で ) 5.rsync minifyと静的コンテンツリリースのJob化 As-Is 作業サーバ Jenkinsサーバ 開発者 Jobﾎﾟﾁｰ 運用Tが作業用サーバに ログインして手作業でリリース RHEL5(現状) Java6
30. 30. 開発T GhE サーバ Webサーバ 運用Tが手作業でリリース 👉👉👉👉 👉👉 3.rsync2.git pull1.git push プライベートクラウド 開発T GhE サーバ Webサーバ 👉👉👉👉 👉👉 1.git push プライベートクラウド 2.git pull 4. source map 紐付け Before After RHEL5, Java6 といった縛り minifyされても エラーを追うため 3.minify ( Java6で ) 5.rsync minifyと静的コンテンツリリースのJob化NewRelic Browserに SourceMapを連携すると、こんな感じになります
31. 31. プライベートクラウド 開発T GhE Webサーバ 👉👉👉👉 👉👉 3.minify ( Java6で ) 5.rsync1.git push 2.git pull 4. source map 紐付け ❑ 既に存在しているJava6を利用したminify方法を選択 （google-closure-compiler） ❑ 既存と同じレベルのエラートラッキングを継続するた めにSourceMapを連携させる ❑ 風呂敷を広げすぎず、必要な範囲の変更をやりきる minifyされたコードで エラーを追うため minifyと静的コンテンツリリースのJob化 まとめ Jenkinsサーバ 開発者 Jobﾎﾟﾁｰ
32. 32. DOM構造リニューアルの設計
33. 33. DOM構造リニューアルの設計 ❑ コンポーネントの設計と実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計
34. 34. DOM構造リニューアルの設計 ❑ コンポーネントの設計と実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計 - コンポーネント洗い出し - 仕様の整理と把握 - 粛々と実装 - コーダーからHTMLなどを受け 取って開発者がマージ - 組み込み時に考慮漏れがあり手戻りが ある場合もあるので、改善する - 人間がやらなくていい仕事を減らし てコード品質の下限を底上げ - レビューは本質に注力できるように
35. 35. DOM構造リニューアルの設計 ❑ コンポーネントの設計と実装 ❑ ルール整備・静的解析・フォーマッタ導入 ❑ HTML/CSS/JS取り込みフローの改善 ❑ 本番装着のための運用設計 - コンポーネント洗い出し - 仕様の整理と把握 - 粛々と実装 - コーダーからHTMLなどを受け 取って開発者がマージ - 組み込み時に考慮漏れがあり手戻りが ある場合もあるので、改善する - 人間がやらなくていい仕事を減らし てコード品質の下限を底上げ - レビューは本質に注力できるように
36. 36. 本番装着のための運用設計 ホットペッパービューティー ヘアサロン ページ ヘアカタログ 予約導線 SEO向け ページ … ❑ アプリケーション大規模リプレイスの影響で機能ごとにモ ジュールが分割される予定 ❑ そのためデプロイなどのモジュール単位になってしまう
37. 37. 本番装着のための運用設計 ホットペッパービューティー v2 v1 v1 v1 ヘアサロン ページ ヘアカタログ 予約導線 SEO向け ページ … ❑ アプリケーション大規模リプレイスの影響で機能ごとにモ ジュールが分割される予定 ❑ そのためデプロイなどのモジュール単位になってしまう ❑ ファイルについてはRailsやSpringはmanifestファイルで解決 できそうだが、DOMの反映はどうするか… リリースタイミン グによっては1つだけ v2ということも
38. 38. 本番装着のための運用設計 ホットペッパービューティー v2 v1 v1 v1 ヘアサロン ページ ヘアカタログ 予約導線 SEO向け ページ … ❑ アプリケーション大規模リプレイスの影響で機能ごとにモ ジュールが分割される予定 ❑ そのためデプロイなどのモジュール単位になってしまう ❑ ファイルについてはRailsやSpringはmanifestファイルで解決 できそうだが、DOMの反映はどうするか… ❑ 具体的な方法は検討中 リリースタイミン グによっては1つだけ v2ということも
39. 39. Rails/Springを理解できる人材 HTML/CSS/JSの密結合 リプレイスしない場合の事業影響言語化 技術・組織課題が混ざって難しい フロントエンドの負債 HTML納品フローによるマージコスト !importantが1,590回 CSSアーキテクチャを理解できる人材 FWの教育コスト モジュールごとのバージョニング方法 ントエンドの守備範囲 静的解析ツールが入ってない Webpackの装着方法 他案件とのコンフリクトは？ 事業価値にどれだけ貢献できるか 既存開発フローの影響範囲 スコープはどこまで 自走できる人材
40. 40. Rails/Springを理解できる人材 HTML/CSS/JSの密結合 !importantが1,590回 CSSアーキテクチャを理解できる人材 FWの教育コスト モジュールごとのバージョニング方法 フロントエンドの守備範囲 静的解析ツールが入ってない Webpackの装着方法 自走できる人材 他案件とのコンフリクトは？ 既存開発フローの影響範囲 スコープはどこまで？ 整理して1つずつ向き合っていく フロントエンドの負債 HTML納品フローによるマージコスト 事業価値にどれだけ貢献できるか リプレイスしない場合の事業影響言語化
41. 41. Rails/Springを理解できる人材 HTML/CSS/JSの密結合 事業価値にどれだけ貢献できるか !importantが1,590回 CSSアーキテクチャを理解できる人材 FWの教育コスト モジュールごとのバージョニング方法 フロントエンドの守備範囲 静的解析ツールが入ってない Webpackの装着方法 自走できる人材 他案件とのコンフリクトは？ リプレイスしない場合の事業影響言語化 既存開発フローの影響範囲 スコープはどこまで？ 更に課題が見つかるので向き合い続ける フルリプレイス一択 どのレベルがあればいい？ パートナー会社に温度感 聞いてみる？ 静的解析ツールCIで回したい Webpackの装着って どのレイヤーまで？ 静的解析ツールCIで回したい Webpackの装着ってどこま で？ 定義がないから 定義から 今期走る案件確認、大きい 案件あったらマージどうするか リプレイスTにも調整しよ フロントエンドの負債 HTML納品フローによるマージコスト HTML4…
42. 42. 地味で長期的な取り組み しかし近道はないので 地に足をつけて向き合う .💪💪
43. 43. ❑ 美容事業は成長しつづけている、そのため 事業成長を続けるために改善を行う ❑ 事業規模が大きいゆえに技術的な課題だけ ではなく組織的な課題とも向き合う必要が あり、仕事の難度が高い ❑ 逆に自分の推進するプロジェクトが数百億 規模の事業に影響するのでやりがいがある . まとめ 😽😽
44. 44. ご清聴ありがとうございました