Webフロントエンドの秩序を維持する体制を作る

by mizdra

Slide 1

Slide 1 text

Webフロントエンドの  秩序を維持する体制を作る  Hatena Engineer Seminar #15  2020/12/23   

Slide 2

Slide 2 text

自己紹介  ● id:mizdra  ● はてな2020新卒  ● マンガメディア開発チーム  ● コードを書くのが趣味  ○ Webフロントエンド 

Slide 3

Slide 3 text

GigaViewer  ● 社内で開発しているマンガビューワ  ○ ブラウザで漫画を読むための機能を提供  ○ ビューワ / トップページ / 検索画面 / 管理画面 / …  ● 出版社様向けに提供  ○ 9社・11のサイトで採用 

Slide 4

Slide 4 text

少年ジャンプ＋ (集英社様) 

Slide 5

Slide 5 text

webアクション (双葉社様) 

Slide 6

Slide 6 text

まだまだ成長中 

Slide 7

Slide 7 text

id:mizdra のチームにおける普段の活動  ● フロントエンド会  ○ GigaViewer のフロントエンドを改善する会  ● 5月に立ち上げてから約半年経った  ● 色んなことがあったので色々良い話をします 

Slide 8

Slide 8 text

フロントエンド会  立ち上げの経緯 

Slide 9

Slide 9 text

立ち上げ当時のチームの状況  ● いままで  ○ 1人の職人が専属でフロントエンドを見ていた  ● しかし id:mizdra の入社と共に異動に  ○ フロントエンドの面倒を見る人が不在に 

Slide 10

Slide 10 text

立ち上げ当時のチームの状況  ● 皆主にバックエンドを触っている  ○ それほどフロントエンドに詳しい訳でもない  ○ 片手間でちょっとしたことをするくらい  ● 難しい問題がやってくると手に負えない状態  ○ 異動された方にお任せしていた  ○ フロントエンドが属人化していた 

Slide 11

Slide 11 text

なんとかしよう  ● 持ち回り制でやってみる?  ○ 片手間でできないとなると非現実的  ○ かといって1人にお任せすると異動や退職で困る  ● 得意な人/興味のある人で集まって専門者集団を作るのはどうか  ○ チームメンバー3人で「フロントエンド会」を結成 

Slide 12

Slide 12 text

フロントエンド会での  取り組み 

Slide 13

Slide 13 text

npmパッケージのアップデート  ● npmパッケージのバージョンが古びていた  ○ majorアップデートが30件  ● Breaking Changeが積み重なり、アップデートが難しい状態  ○ 上げようと思っても中々上げられない  ○ とはいえ放置するとどんどん困難に  ● セキュリティ上のリスクも  ● まずはこれから取り組むことに 

Slide 14

Slide 14 text

とはいえ...  ● メンバーのスキルセットはバラバラ  ○ 何でもできます〜趣味でちょっとした物を作ったりできます  ○ パッケージのアップデートをどうやれば良いか分からない人も  ● 出来る人だけやっても仕方がない  ○ 再び属人化してしまう  ○ そもそも複数人で集まっている意味がない 

Slide 15

Slide 15 text

会の運営方針  ● それぞれが知識を学び、自走できるように  ● そのために...  ○ 識者が積極的に知識を配っていく  ■ やり方をレクチャーしたり、ドキュメントを書いたり   ○ 簡単に進められるよう道を整備する  ■ 便利なツールやサービスを導入する   ○ 自走できるようになるまでフォローする  ■ ペアプロやモブプロを積極的に活用   ● => 属人化も解消され、より高速に進められるようになるはず 

Slide 16

Slide 16 text

npmパッケージのアップデートにおける工夫  ● Renovateを活用  ○ パッケージをアップデートするPRを自動で作ってくれる  ○ PRにCHANGELOGへのリンクなどがあり、効率的に作業できる  ● モブオペを活用  ○ アップデート作業には知識が必要  ■ ライブラリの機能や用途   ■ CHANGELOGの眺め方   ■ Breaking Changeがプロダクションに影響があるかを判断する方法   ○ 識者と一緒に作業し、知識を共有する 

Slide 17

Slide 17 text

結果  ● 1ヶ月後には自走し始めるように  ● npm パッケージをアップデートしていく習慣ができた  ● 半年後には major が 30 => 8 に  ● あとは gulp とかアップデートするより脱出したいもの  ○ ひとまず安心できる状態に 

Slide 18

Slide 18 text

パッケージのアップデートが落ち着いてきた  ● 設立から2ヶ月経過  ● 他のことをやる余裕が出てきた  ● 識者が沢山居ることを生かして何かやりましょう  ○ フロントエンド相談窓口  ○ 巨大な問題の解決 

Slide 19

Slide 19 text

フロントエンド相談窓口  ● フロントエンドタスクの相談や見積もり、実装の依頼などを受け付ける活動  ● 例  ○ マンガが表示されない原因を調査してほしい  ○ 格好良い機能を作りたいのだけど実現できそう?  ○ 自信無いので一緒にタスク分割や見積もりしてくれませんか  ● こうしたタスクを会で引き受けていった 

Slide 20

Slide 20 text

難しいところ  ● 色んな種類のタスクがやってくる  ○ ビューワだったり広告だったりビルドパイプラインの話題だったり  ○ 人によって詳しかったり詳しくなかったり  ○ １人で全部やるのは難しい  ● 結構タスクがやってくる  ○ 専属ならまだしも1人で片手間で捌くのは難しい 

Slide 21

Slide 21 text

複数人であることを活かして進める  ● まずはタスクを会の議題として取り上げる  ○ 実装方針を決めたり、タスクを分解したり  ○ 進め方のイメージがつくようになるまで議論する  ● 興味のある人や余裕のある人にお渡しする  ○ 不安があるなら一緒にペアプロして倒す  ● => 複数人で協力して短時間で片付ける 

Slide 22

Slide 22 text

巨大な問題の解決  ● チームの力で巨大な問題を倒す活動  ● 代表例: ビューワのメモリリーク問題  ○ ページをめくっていくとモリモリメモリ使用量が増えていく  ○ 開発初期から存在していた  ○ ユーザからのお問い合わせもなかったため、優先度が低かった   

Slide 23

Slide 23 text

問題発生  ● 今年の7月になってページ画像が表示されないとの報告が  ○ ページ数が多い作品だと上限に達してページ画像が表示されなくなる  ○ 報告件数も徐々に増えてきた  ○ 怪しい雰囲気  ● 11月に人気のある雑誌の定期購読サービスが始まる  ○ 500Pくらいある  ○ なんだか嫌な予感  ● なんとかしよう   

Slide 24

Slide 24 text

めちゃめちゃ難しい  ● メモリリークが発生している理由(ページめくり)に見当は付いていた  ○ 一方どう修正すれば良いかは不明  ● GCの仕組み / メモリリークが発生する仕組み / メモリリークを引き起こすコードパターンに関する知識  ● そもそもビューワはGigaViewerで特に難しいとされる部分  ○ 複雑なコードを読み解き、的確な修正をしなければならない   

Slide 25

Slide 25 text

どう進めたか  ● GCの仕組みやメモリリークの仕組みについて勉強することに  ○ 偶然 id:mizdra が趣味でメモリリークに取り組んでいた  ○ その知見を元に会向けの学習資料を用意 

Slide 26

Slide 26 text

どう進めたか  ● 資料を元に修正箇所や修正方法について議論  ○ 古いページ (Nページ前) のDOMは捨てるよう改良することに  ● その後方針通りに実装  ○ ピタリとメモリリークが収まる   

Slide 27

Slide 27 text

Before     

Slide 28

Slide 28 text

After     

Slide 29

Slide 29 text

After     

Slide 30

Slide 30 text

良かったこと  ● メモリリーク識者が居た  ○ 取っ掛かりができた  ● ビューワのアーキテクチャの識者が居た  ○ 修正箇所の特定や修正方法がすんなり決まった   ● 学習資料で知識が底上げされた結果、メンバー全員で実装イメージが共有できるように  ○ 実装もレビューも全員自信を持ってできるように    => 複数人で協力して安定して進めることができた 

Slide 31

Slide 31 text

これにて一段落 

Slide 32

Slide 32 text

順調に課題を解決して来たが…  ● ある日Dから相談が  ○ 「会の目標や存在意義を明確にしてほしい」  ● よくよく話を聞いていくと  ○ フロントエンド会に対してどういう期待をしてよいのかよく分からない  ○ タスクを任せづらい 

Slide 33

Slide 33 text

振り返ってみると  ● フロントエンドの秩序を維持する、みたいな目標で行動してきた  ○ ふわっとしている  ○ 「秩序とは? 保守運用のこと?」  ○ 「実装の相談に乗って欲しいのだけど保守しかやってくれないの?」  ● 本当は相談なども引き受けたい  ○ しかし目標が不透明なせいで混乱が生じていた 

Slide 34

Slide 34 text

目標を整理する  ● これを機に一度目標を整理してみることに  ● 今までの活動実績や会のメンバーの意見を元に、会に期待されていること /会でやりたいことを書き出していく  ● まとめて「フロントエンド会で担いたい仕事」としてチームに告知 

Slide 35

Slide 35 text

フロントエンド会で担いたい仕事  1. フロントエンドの開発支援  ○ タスクの見積もりや壁打ちやります  ○ レビュー引き受けます  ○ 企画やデザインでやりたいこと・導入したいツールがあれば支援します  2. フロントエンドの課題解決  ○ メモリリークのような難しい問題倒します  ○ パフォーマンス改善やります  ○ 新技術導入やります 

Slide 36

Slide 36 text

結果として  ● 「この話題はフロントエンド会に相談しよう」と判断しやすく  ● Dからも気持ちよくGOと言えるように  ● 会の指針があることで互いに信頼し、連携しやすく 

Slide 37

Slide 37 text

その後 

Slide 38

Slide 38 text

その後、最近の取り組み  ● 保守や相談窓口の活動 (いわゆる守りの活動) が会で回せるように  ○ 秩序を維持する体制が整った  ● しかし守りだけでは出せる価値に限界がある  ○ 秩序を維持する以上のことができない  ● 守りだけでなく攻めもできるようになろう  ○ 最新技術の導入 / パフォーマンス改善 

Slide 39

Slide 39 text

パフォーマンス改善  ● ユーザにより快適に、ストレスなく使ってもらえるように  ● パフォーマンスの指標の検討に始まり、パフォーマンス測定基盤の構築、測定結果の分析...という流れで進む  ○ 今ようやく実際にパフォーマンスの改善施策を導入していこう、という段階 

Slide 40

Slide 40 text

現在の課題  ● 具体的な実装イメージを会で共有できていない  ● dev-toolsを使い、当たりを付けていく...ことまではできている  ○ コードのどこをどういじれば良いか、が共有できていない  ● 原因: Frontend-Ops の深い知識が要求されるため  ○ Frontend-Ops: アプリケーションコード以外のこと  ○ 実はパフォーマンス改善テクの殆どは Frontend-Ops に関連  ■ Web Speed Hackathon Online 出題のねらいと解説   ○ アプリケーションコードよりは基盤をいじるのが主  ○ Frontend-Ops に詳しい人が id:mizdra 以外にいない 

Slide 41

Slide 41 text

検討中の案  1. id:mizdra が会に割く時間を増やす  ○ 属人化時代に逆戻りになってしまいそう  2. 会の皆でFrontend-Opsを学ぶ  ○ id:mizdra がレクチャー  ○ パフォーマンスチューニングの力を付ける  => パッと見た感じでは2が良さそう 

Slide 42

Slide 42 text

しかし...  ● 会がどんどん高度化して、人の入れ替えが困難になる可能性  ○ 新規メンバーの受け入れや異動・退職で困りそう  ○ 会を持続可能な形でどう発展していくかが課題 

Slide 43

Slide 43 text

まとめ 

Slide 44

Slide 44 text

まとめ  ● 秩序を維持する体制を作る話をした  ● フロントエンド会の立ち上げ  ● 自走する力をつけて、属人化を解消する  ● 会の指針を出し、チームやDとの連携を図る  ● 価値を高めるため守りだけでなく攻めもやる  ● フロントエンドの属人化から会の持続性に話題がシフトしつつある 