Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
巨大なSPAの技術的負債と向き合い続けるテクニック
Search
shibe23
May 17, 2023
Technology
3
2.5k
巨大なSPAの技術的負債と向き合い続けるテクニック
「フロントエンドの技術的負債 みんなで学ぶ Lunch LT 」の登壇資料です
https://findy.connpass.com/event/281811/
shibe23
May 17, 2023
Tweet
Share
More Decks by shibe23
See All by shibe23
巨大なSPAの技術的負債と向き合い続けるテクニック(2023年秋)
shibe23
4
8k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
1.8k
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
1
410
マネージャーからみたスクラムと自己管理化
shibe23
1
2.3k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
5.8k
Other Decks in Technology
See All in Technology
コンテナ・K8s研修 - 後半 Kubernetes 基礎&ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
1
120
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
データ分析基盤を作ってみよう~設計編~
nrinetcom
PRO
1
110
AWSでRAGを作る法方
sonoda_mj
1
140
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
ソフトウェアエンジニアリングの知見を活かして データ基盤をいい感じにする on Snowflake [MIERUNE BBQ #10]
mtpooh
2
150
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8k
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
470
Featured
See All Featured
It's Worth the Effort
3n
181
27k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Six Lessons from altMBA
skipperchong
24
3.2k
Side Projects
sachag
451
42k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
Happy Clients
brianwarren
94
6.5k
Statistics for Hackers
jakevdp
792
220k
How GitHub Uses GitHub to Build GitHub
holman
471
290k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Transcript
© Chatwork 巨大なSPAの技術的負債と 向き合い続けるテクニック 2023年05月17日 フロントエンド開発部マネージャー 澁谷 哲也 Chatwork株式会社
自己紹介 2 Chatwork株式会社 澁谷 哲也 Tetsuya Shibutani フロントエンド開発部 マネージャー ビジネスチャットツールを作っています @shibe_23
ChatworkのWebFrontendについて
ChatworkのWebFrontendの特徴 • 巨大なSPA、かつ利用中ほとんどリロードされずに使われるアプリケーション • 双方向性があり、ユーザーからのアクション以外で状態が変わる • JavaScriptだけで16万行 • CSSも1万7千行 ◦
Styled-Componentを利 用しているため、実際に はもっと多い 巨大なコードベース • ブラウザベースのアプリケー ションとしては珍しく、URL単 位でアプリケーションとして分 割されていない • 再読み込みのない一枚のページ で全UIが動作している 純粋なSinglePageApplication • Webサイトベースの「入力 -> 確認 -> 完了」と情報が一方向 なWebアプリではない • Google SpreadSheetのような GUIアプリとしての複雑さを持 つ GUIアプリとしての複雑性 4
技術的負債の状況 • jQuery -> React + DDD -> React +
Reduxの3世代に渡るアーキテクチャ • jQuery製のUIとReact製のUIが混在している ◦ 全体のうち約2万4000行がjQuery製 • 認知的複雑度(Cognitive Complexity)の合計は、およそ9,000 ◦ jQuery世代はおよそ5,000 • 各世代ごとの詳細は下記を参照ください 組織フェーズを見据えたWEBフロントエンドのアーキテクチャと変遷(JS Conf 2021)
技術的負債についての考え方 • 技術的負債は「アプリケーションのあるべき姿と現状との差分」 ◦ 現状からあるべき姿に到達するまでに掛かる時間(= リソース)と向き合っている • あるべき姿は時代の変化によっても変わる ◦ jQuery全盛期にReactの登場は予測できなかった
◦ 現在のベストプラクティスも、新しい技術の登場によってあるべき姿から遠ざかる • 負債は無くすものではなく、様々な要因を加味してコントロールするもの 技術的負債と継続的に向き合う仕組みづくりが重要
技術的負債と継続的に向き合う方法 7 1. 段階的に返却するためのテクニック 2. 安全にリリースするための仕組み 今回は具体例をいくつかご紹介します
段階的に返済するテクニック
jQueryの世界とReactの世界を分離する • jQuery製のコードとReact製のコードの間に腐敗防止層を設ける • interfaceをReact側から提供することで依存関係を制御する • Reactの世界にjQueryが侵入することを防ぎ、古いコードを捨てやすくしている jQuery時代のアーキテクチャをReact化するために大切なACL層のお話
jQuery製のUIとReact製のUIを混在させる • 段階的にリファクタリングするためにUIごとにReact化したい • ReactDOM.renderを使った時の課題 ◦ Context APIを全てのレンダリングツリーに流し込む必要性 ◦ デバッグ時にレンダリングツリーごとにしかプロファイルが取れない
• ReactDOM.createPortal で同一の親コンポーネントを指定してマウントするようにした • 部分的な置き換えにおける注意点 ◦ イベントハンドラの多重登録 ◦ 再描画の度にjQueryで作成したDOMが残り続けることによるメモリリーク … React … jQuery
TypeScriptのStrict modeを有効にする • jQuery時代のコードはany型を一部許容している ◦ 一方で、普段のコードを書く時に暗黙的なany型の混入を防ぎたい • strictを有効にするために、TypeScript Compiler APIを使って型エラーが起きている箇所に
@ts-expect-error を自動で追加した ◦ 新規で@ts-expect-errorを書かないようにpre commit時にチェックしている • 型エラーが隠蔽されるケースがあるので、トレードオフには注意
安全にリリースするための仕組み
技術的負債と継続的に向き合う = 小さく試して改善し続ける • コードを適切に処理できれば確実に不具合を回避することはできるか? ◦ できない ◦ 負債の影響は積み重なって予期しない不具合として現れる •
リリースしなければ本当に問題がないかは確認できない ◦ 失敗の影響を最小限に抑えなければ、リファクタリングは重たいプロセスになってしまう • “どうコードをきれいにするか”も大事だが、 “小さく失敗できる体制をつくる“ことが最も重要
リリースフローの全体像 • GitHub Flowを採用 • mainブランチにマージされるとすぐに社内検証ユーザーにデプロイされる • 本番リリースされるのは、その時点のmainブランチの最新コミット • 先行して自分たちが触ることで、ユーザーにとって致命的な不具合がリリースされることを回避
社内検証ユーザーにリリー ス main feature-x 社内検証されたものが 本番リリース
コミットハッシュごとのスナップショットを生成する • PR作成時 / 更新時 / mainブランチへのマージ時にビルドしたjsファイルをS3にアップロードする • コミットハッシュをURLにパラメータとして付与することで、指定したバージョンでアプリを開いて 検証できる仕組みがある
◦ バージョンごとの現象確認が容易 • リリースブランチへマージされた履歴がjsファイルとして既に生成されている、というのがポイント commit hash: c63df1b164b73d71… main commit hash: f632892477af9be29… commit hash: ebbd2436080a165c… commit hash: 8238f9b315116c5c0…
自前のリリースシステムで高速なリリース / 切り戻しを実現する • リリースは生成済のjsファイルを本番環境にコピーするだけ • mainブランチの過去の状態も保存されているため、切り戻しも容易 • 緊急時の切り戻しは実行 ->
リリース完了で約3秒 ※ 切り戻しの判断も必要なので、障害対応自体はもう少しかかります
Feature Toggleで安全にリリース内容を制御する • Feature Toggleで社内検証ユーザーにのみリリースすることができる • 大きめのリファクタリングなど、本番環境へのリリースを阻害することなく検証期間を設けることが できる • 非公開の制御もFeature
Toggleをオフにするだけ • Feature Toggleによって分岐が増えて複雑化する場合もあるため要注意
まとめ
技術的負債と現実的に向き合うために • 技術的負債を解消するより、どのように距離を保つか ◦ 段階的に負債を返却するためのテクニック ◦ 安全にリリースするための仕組み • 未来は誰にも予測できない。だからこそ小さく試して改善し続ける ◦
“小さく失敗できる”体制が重要
今回の話に興味を持っていただいた方へ • エンジニアHub様掲載の記事もご覧ください React+Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計
最後に • Chatworkではフロントエンドエンジニアを募集しています • 巨大なSPAと一緒に向きあい改善し続けてくださる方、ぜひご応募ください! 採用ページはこちら
働くをもっと楽しく、創造的に