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.7k
巨大な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
8.6k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
2.1k
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
1
580
マネージャーからみたスクラムと自己管理化
shibe23
1
2.4k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
6.1k
Other Decks in Technology
See All in Technology
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.9k
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
130
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
270
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
20250705 Headlamp: 專注可擴展性的 Kubernetes 用戶界面
pichuang
0
270
ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring
visional_engineering_and_design
1
120
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
960
Claude Code に プロジェクト管理やらせたみた
unson
6
4k
freeeのアクセシビリティの現在地 / freee's Current Position on Accessibility
ymrl
2
190
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
340
ゼロからはじめる採用広報
yutadayo
3
920
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
77
9.5k
We Have a Design System, Now What?
morganepeng
53
7.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Rails Girls Zürich Keynote
gr2m
95
14k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
Faster Mobile Websites
deanohume
307
31k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
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と一緒に向きあい改善し続けてくださる方、ぜひご応募ください! 採用ページはこちら
働くをもっと楽しく、創造的に