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.8k
巨大なSPAの技術的負債と向き合い続けるテクニック
「フロントエンドの技術的負債 みんなで学ぶ Lunch LT 」の登壇資料です
https://findy.connpass.com/event/281811/
shibe23
May 17, 2023
Tweet
Share
More Decks by shibe23
See All by shibe23
チームと一緒に育つために考えたこと - 属人性・期日・関係性のバランスと向き合う
shibe23
0
62
巨大なSPAの技術的負債と向き合い続けるテクニック(2023年秋)
shibe23
4
8.7k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
2.1k
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
1
600
マネージャーからみたスクラムと自己管理化
shibe23
1
2.5k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
6.2k
Other Decks in Technology
See All in Technology
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
5.4k
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
210
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
420
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
180
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
320
extension 現場で使えるXcodeショートカット一覧
ktombow
0
210
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
140
Findy Team+のSOC2取得までの道のり
rvirus0817
0
340
BtoBプロダクト開発の深層
16bitidol
0
330
How to achieve interoperable digital identity across Asian countries
fujie
0
120
20250929_QaaS_vol20
mura_shin
0
110
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Mobile First: as difficult as doing things right
swwweet
224
10k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
960
How GitHub (no longer) Works
holman
315
140k
The Cult of Friendly URLs
andyhume
79
6.6k
The Straight Up "How To Draw Better" Workshop
denniskardys
237
140k
Faster Mobile Websites
deanohume
310
31k
Docker and Python
trallard
46
3.6k
Speed Design
sergeychernyshev
32
1.1k
Unsuck your backbone
ammeep
671
58k
Music & Morning Musume
bryan
46
6.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
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と一緒に向きあい改善し続けてくださる方、ぜひご応募ください! 採用ページはこちら
働くをもっと楽しく、創造的に