未学習領域におけるチーム{学習,プレイ}とは /au Web portal frontend, BIT VALLEY -INSIDE- Vol.8

au Web ポータルにおけるフロントエンドの取り組み。
チーム学習とは、チームプレイとは。

Transcript

1. au Web ポータルにおける フロントエンドの取り組み 未学習領域におけるチーム{ 学習, プレイ} とは 2019-04-17 BIT VALLEY -INSIDE- Vol.8
2. Who { { "name" "name" : : " 武田 諭" " 武田 諭", , "social" "social": : "@tkdn" "@tkdn", , "from" "from" : : " 株式会社 mediba" " 株式会社 mediba", , "dept" "dept" : : "CD 本部創造開発部／ものづくり推進部" "CD 本部創造開発部／ものづくり推進部", , "work" "work" : : " フロントエンドエンジニア" " フロントエンドエンジニア", , "word" "word" : : " ブラウザが主戦場" " ブラウザが主戦場" } }
3. Who 1980 年生まれ, 38 歳 2003 ～2013 俳優業 2013 ～2017 エンジニア転向、受託開発など 2017 ～ mediba, 入社2 年目
4. 今日の話は au Web ポータルのリニューアルにおける取り組み 未学習領域におけるチーム学習 チームにおける学習に必要なものはなんだろう テクニカルなことにはあまり触れません
5. アジェンダ au Web ポータルリニューアルに際して、 1. 何を変えたか 開発チームの体制, チーム再編による技術刷新 2. どう取り組んでいったか 学習における課題, 具体的な取り組み 3. チームは , わたしは何を学べたか
6. 何を変えたか #1 開発チームの体制
7. From Front-End : Server-Side = 4 : 8
8. To Front-End : Back-End = 9 : 3
9. 比率の変更の理由 事業成長に伴う施策はフロントエンドがメイン 人的リソースの効率化を行うため, 比率の変更 技術的な成長要素と市場価値の創出
10. フロントエンド？ ブラウザ・クライアント アプリケーションコード BFF （API ） クライアントサイドのトラブルシュート までの範疇を広義のフロントエンドととした
11. 何を変えたか #2 チーム体制変更による技術刷新
12. From Server-Side: Yii Framework （PHP ） Front-End: jQuery, Backbone.js Server: apache, and other middlewares Infra: self-uncontrollable な環境
13. チーム体制変更に見合った技術選定 広義のフロントエンド領域において境界を失くす 言語の違いによるコンテキストスイッチを減らす 共通言語によりapp コミュニケーションコストを下げる
14. To ✏ : TypeScript TypeScript : Next.js Next.js ⚛ : React/Redux React/Redux, w/ reselect, redux-thunk : express express : graphql-yoga graphql-yoga, express-based Infra: AWS へ移管, ECR + ECS/Fargate...
15. TypeScript, 全員ほぼ未経験 React/Redux, 全員ほぼ未経験 Node.js によるフロントサーバ, 全員未経験 GraphQL, 何それ美味しいの どう考えても風呂敷広げすぎ問題 さてどうしていくか …
16. どう取り組んでいったか #0 チーム学習における課題を考える
17. 考える前に 各スキルセット整理 旧フロントエンド 渉外的なやりとりにおいてバリューを発揮 コミュニケーションブリッジとなるシーンも多い app エンジニアとしてのハードスキルが不足
18. 各スキルセット整理 旧サーバサイド 経験値・ハードスキルが高い サーバサイド PHP を触っていた人たち クライアント・ブラウザについては弱い
19. どのように学習していくかを考える バックグラウンドが違うメンバーが ゼロベースの新しいスタックに どう効率的に学習していくのか
20. 初手 : とにかく伝搬 自ら吸収したものをとにかく伝搬しまくる ドキュメントを和訳して Slack で展開 => 届け、誰かに PoC を実装, コードで展開 => 読んで、コードを 突然あらわれるライフサイクルメソッドおじさん ※ React 16.3~ lifecycle method が deprecated になるタイミング => ついてきてー
21. 知っていることを提供できても メンバーに伝播できているとは限らない さて二手目、どうしようか…
22. どう取り組んでいったか #1 がんばらない TypeScript
23. Why TypeScript ? クラスベースの OOP 言語なら サーバーサイドの人も入りやすいはず 既存のフロントエンドはJS を触ってきている （TypeScript は JS のスーパーセットやろ ｸﾁｬｸﾁｬ
24. 触ってみて 型定義、なにそれ美味しいの？ 全然型通らない… なぜコンパイルできない… VSCode が赤くなって何がなんだかわからない…
25. プロジェクト初期 @__gfx__ さんに相談した ＜ 型付けをがんばらない
26. がんばらないTypeScript のはじめ方 - 角待ちは対空 any でもいいじゃない。詰むより作る、前に進む 慣れてくると良さや勘所がだんだんわかってきた any で逃げたところもきっちり型付けしだした TypeScript… これはいいものですね
27. 静的なコンポーネントから Atomic Design で構成したコンポーネント tsx を静的に実装 Props, ローカル State の型付け, interface の規約などを作り慣れていった 序盤で TSLint ルール整備 pre-commit hook によりコードの一貫性は最初から保てた
28. ある程度慣れてからの メンバーの TypeScript への感想 JavaScript というゆるふわな言語を TypeScript がガチッとフォローしてくれて良い Flow を書いていた時よりもガッツリと型を書いている感じがあって最高 VSCode の補完が最高すぎて生産性が爆上がりした 型定義する時に逃げることがあった（any でもOK という安全性も大事）
29. 厳格なスタートを切らない 学習序盤からゆるふわでスタートしても 最終的に変更・修正できる容易性の方が重要
30. どう取り組んでいったか #2 Redux とペアプロ
31. "Redux は学習コストが高い " 知ってる
32. 2, 3 名のチーム別に伝達するフェーズ Redux おじさんによる概念説明 アプリケーションをグローバルに状態管 理できる Pub/Sub パターン！ カスタムイベントあるじゃないです か！？ イベント来たら反応するめっちゃ便利な オブザーバー！ なんかすごい便利なやつ（語彙力
33. 概念的なものは伝わったという意味では 効果はあったのかもしれないが 実装レベルに落とせていない これは思ったより実装までのリーチがだいぶ長いのでは… ？ React / Redux の習熟度が高いメンバーがジョイン
34. 習熟度の高いメンバーを中心にペアプロを行った ※ 一般的なペアプロとは乖離があるかもしれません。 1. 朝会で機能ベースでペアを決める 2. ペアで時間を決めて自由にスタート 3. VSCode LiveShare を使う 4. ドライバー・ナビゲーターはなんとなく 5. 3,4 時間使って集中的に
35. 広義の FE チーム内でペアプロをする利点 得意なフィールドによって交代できる 得意なフィールドであれば検索能力も高く 参考資料として Slack にURL 貼り付け GraphQL 側の Logic って？ Resolver って？ 違うフィールドへの理解を深められるメリット 適宜交代することで得られるスピード感もある
36. 雑談から得られる利点 Tech な話題が多くなり自然とそんな会話になりやすく雑談の質が上がる 共通関数作りたくなる派, 時期尚早まだ共通化しない派など個人の特性が わかる 考え方の違いが出てきたりなど初めて知る部分も多い
37. ⏱ 時間的な制約の中で得られる利点 機能実装の本質に効率的に近づける 個人でやるとリファクタしたくなるところを、今は機能を実装しようと いうスタイルになる 一人で出来ることは後回し、機能実装を優先できる 一人だと不要な yak shaving をやってしまいがちだが抑止できる
38. デメリット 口頭伝承スタイルになるのでドキュメントが残らない 知見がどうしてもペアを組んだエンジニア同士で留まってしまう PR も合意が得ているのでレビューを通さないようなスタイルだった それら度外視しても、ペアプロいいものですね
39. ある程度慣れてからのメンバーの感想 Redux 関連で詰まってることが多かったので LiveShare / ペアプロで進捗がかなり上がった 理解してくると便利に思えてきた 自分はペアプログラミングが結構効いている、質問する時間も省けたり、会話しながらだと理解力も全然 違ってとにかく効率良く学べた
40. 自学自習には限界がある 対話しつつ機能を作っていくほうが チームには効率的なシーンがある 雑談、めっちゃ大事 ペアプロ、めちゃくちゃいいものですね
41. どう取り組んでいったか #3 React client tuning と信頼
42. dev 環境も出来てきたしデプロイしてみたら インタラクションがもっさりしている… リニューアル前のサクサクした感じがない… スクロールによるメモリ不足でブラウザタブが落ちる始末… 機能実装優先で 細部のパフォーマンスまで意識出来ていなかった
43. 計測によるもっさり検出 もっさりの感覚値をきちんと確認 Chrome DevTools Performance タブ ユーザインタラクションが発生した 後に出ている violation （違反）をまず 拾い上げる 不快感は遅延したフィードバックが 主な原因(200ms から違和感)
44. いつ violation が出る？ ユーザイベント（click, touchend, scroll... ）によるハンドラ実行完 了まで時間がかかった JavaScript 実行時に強制的に re ow が走った document.write を使用した イベントに対して非効率なハンドラのアタッチが行われた ... etc
45. メンバーに伝搬 習熟度の高いメンバーがサンプルになるようなPR を作成 勘の鋭いメンバーにチューニングの肝を伝搬 計測・仮説（改修実装）・検証、根気のいる作業なので単独作業とし成 果をPR でレビュー
46. violation どう潰す？ インタラクションに紐づくイベントへアタッチされた処理から見ていく ことにした Performance タブで採取した情報を元手にハンドラを追っていく 詳細計測はUser Timing API を使った計測（React v16 から可能）
47. パフォーマンスを意識せず富豪実装してい った結果 ほとんどがコンポーネントのムダなアップ デート 主だった要因としてはスタティックなコン ポーネント実装時にすべて FC で実装して いたため
48. マズそうなコンポーネントを洗い出し 適宜 React.memo 化、ムダなアップデート抑止 shouldComponentUpdate で適切にアップデートを抑止 onClick に arrow-function をそのまま渡していないか（ tslint-react: jsx- no-lambda rule ） shallow equal の比較よりも FC で再レンダリングした方がコストが低い場 合があるので注意 ... etc
49. 勘所を抑えたメンバーが大改善
50. UI コンポーネントから大量に作ったのが仇となった 後半でパフォーマンス等の整合性取るのはなかなか大変 信頼ベースでタスクを委ねる
51. チームは , わたしは何を学べたか learn and delegate
52. 個人の気づき 伝播だけでは空回りしてリーチしない 自分が独習できた環境とは何かを思い出した 人は最初から自学自習できるわけではない 外的要因や環境の上で学習できたに過ぎない
53. ゼロベースからの チーム { 学習 , プレイ } とは 導入を容易に、障壁を軽減させる環境を 整備することから始めよう
54. 1. 最初からルール立てて厳格なスタートを切らない 学習序盤からゆるふわでスタートしても 最終的に変更・修正できる容易性の方が重要 2. ペアプロ、めちゃくちゃいい 個人の自学自習には限界がある 対話しつつ機能を作っていくほうが チームには効率的なシーンがある 雑談、めっちゃ大事 3. 後半は信頼ベースでタスクを委ねよ
55. リニューアル自身の成功・失敗 少しだけクライアントパフォーマンスの話
56. au Web ポータルですが 実は現在クライアントサイドで React が動いていません CSR はリニューアル以前の Backbone.js, jQuery で動いています
57. 理由 リニューアル後の事業売上＝広告収入が減少 クライアントパフォーマンスの影響と思われる 売上としての選択からReact による CSR から以前のスタックへ
58. 何が問題だったか React.hydrate によるイベントへのアタッチ、クライアントで必要な Fetch に時間がかかり UI が遅延 それらと広告 3rd party スクリプトとの共存においてどうしてもクライア ントサイドのパフォーマンスを上げられなかった
59. リニューアル後のパフォーマンス値 実は数字が良かったりする
60. TTFB の向上 => CDN に Akamai を選択 FirstPaint FCP/FMP ともに向上 => React SSR TimeToInteractive の低下 => アタッチ, Fetch による UI 遅延 e.g. タブ遷移
61. 身内自慢 DataStudio とGAS でWebPagetest の計測結果をグラフ化する | mediba Creator × Engineer Blog gas-webpagetest でWebPagetest のパフォーマンス計測を自動化、可視化す る | Web Scratch
62. 広告表示の優先度を上げるために 事前知識: おおよそ 3rd party はメインスレッドの処理ブロックを引き起こす（`document.write` など） アプリケーションコードをコールバックキューに積んで遅延実行 => 効果はある。UI 遅延を生む。それはそう。オススメしない <link rel="preload"> で 3rd party を投機的読み込み => 効果大。ブラウザの実行優先度を理解するのが良いかも
63. Priority on Browser(Chrome) AddyOsmani.com - JavaScript Loading Priorities in Chrome
64. 数値としてはどのくらい盛り返せたのか リニューアルリリース、その後チューニング for 広告、CSR 等変更してリリース 左: リニューアル前, 右: 諸々変更を加えてのチューニング後リリース 初期描画, FCP/FMP いずれも向上 元々 Akamai の TTFB が早かったのでさらに後続の数値が良くなる UI 完了も早いので準じて広告描画との棲み分けが最適化 広告売上も4 月に入ってきて回復している( まだ経過観察中)
65. 悔しい。あきらめねーぞ React CSR に戻すためには React Concurrent Mode = Async Rendering Scheduling in React UI = メインスレッドをブロックすることなく コンポーネントの描画を適宜スケジューリングできるとみんな幸せそう
66. 以上 ありがとうございました
67. 天下一品 高円寺店 （てんかいっぴん） - 高円寺/ ラーメン づゅる麺池田 （づゅるめんいけだ） - 目黒/ つけ麺 自家製麺 MENSHO TOKYO - 後楽園/ つけ麺
68. 宣伝 フロントエンドランチ ここ 8F でフロントエンドランチを毎週水曜やってます （去年6 月から初めて今日で39 回目でした） Slack にてチャンネルを共有できます 参加のご希望があれば声かけてください！ フロントエンドランチ - mediba We are hiring. Wantedly, Findy... FE 募集してます