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
漸進。
Search
TOMIKAWA Sotaro
May 29, 2025
Programming
0
2.5k
漸進。
TOMIKAWA Sotaro
May 29, 2025
Tweet
Share
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
2.7k
useSyncExternalStoreを使いまくる
ssssota
6
5.5k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.2k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
190
脱法Svelte / Evasion of svelte rules
ssssota
1
210
Documentation testsの恩恵 / Documentation testing benefits
ssssota
2
1k
TypeScriptとDocumentaion tests / Documentation tests with TypeScript
ssssota
8
3.9k
Svelteでライブラリを作る / Make your library with Svelte
ssssota
0
160
現代のReactivityとSvelteの魔法
ssssota
0
2.2k
Other Decks in Programming
See All in Programming
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
110
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
270
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
180
NPOでのDevinの活用
codeforeveryone
0
770
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
590
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
140
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
2.1k
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.2k
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
350
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
100
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
7.6k
Featured
See All Featured
Building Applications with DynamoDB
mza
95
6.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Speed Design
sergeychernyshev
32
1k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
The Cult of Friendly URLs
andyhume
79
6.5k
Raft: Consensus for Rubyists
vanstee
140
7k
Balancing Empowerment & Direction
lara
1
400
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
A designer walks into a library…
pauljervisheath
207
24k
Git: the NoSQL Database
bkeepers
PRO
430
65k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Transcript
漸進。 株式会社ZOZO ブランドソリューション開発本部 WEARフロントエンド部 Webブロック 冨川 宗太郎 Copyright ©
ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO ブランドソリューション開発本部 WEARフロントエンド部 Webブロック 冨川 宗太郎 2022年新卒で株式会社ZOZOに入社。
WEAR by ZOZOのWebフロントエンド開発に従事。 フロントエンド領域のテックリードを務める。 2
© ZOZO, Inc. https://wear.jp/ 3 • あなたの「似合う」が探せるファッションコーディネートアプリ • 1,800万ダウンロード突破、コーディネート投稿総数は1,400万 件以上(2025年3月末時点)
• コーディネートや最新トレンド、メイクなど豊富なファッション 情報をチェック • AIを活用したファッションジャンル診断や、フルメイクをARで試 せる「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレン ト・デザイナー・インフルエンサーといった各界著名人も参加
© ZOZO, Inc. 4 WEAR Webが抱えていた負債 WEARは10年近く運用されてきたプロダクト。 オンプレミスのIISサーバーでVBScriptが動作しjQueryで動きを作っていた。 VBScriptでは独自のテンプレートフレームワークが動き、 Node.jsなどという高尚なツールは使わず手作業でminify/リリースし、
仕様はドキュメント化されていなかった。 →リリース時のミス・時間がかかる 技術スタックの時が10年以上昔で止まっていた。
© ZOZO, Inc. 5 ただし敵ではない 10年近く運用され、多くのユーザーに価値を提供してきた。 VBScriptも独自フレームワークもよくわからないが、動いている。 旧環境は負債であっても、敵ではない。 コードと開発者に敬意を忘れない。蔑ろにすると痛い目を見る。
© ZOZO, Inc. 6 リプレイスという名の再建 リプレイスのゴールは「いまあるものを0に、あたらしいものを100にする」。 と聞くとすべてエイヤで置き換えたくなる。(通称ビッグバンリライト) よく知られた話ではあるが、 ビッグバンリライトはよほどの理由がない限り避ける
© ZOZO, Inc. 7 ビッグバンリライトはダメ(一般論) ビッグバンリライトを避けるべき理由は以下の通り: • 完遂できなかった場合、進捗が0になる • 完遂できても、
◦ 一度に作り切るので設計が洗練されない ◦ 新たな負債へ • スケジュールが立たない・守れない • 仕様の見落とし • 新機能開発が止まる • etc... ※ただしやむを得ない場合や圧倒的腕力がある場合はこの限りではない
© ZOZO, Inc. 8 すこしずつリプレイスするために 1 とにかく旧環境を触り、コードを読む。 仕様がドキュメントにないなら尚更、仕様があっても未知の仕様を拾う。 拾った情報を仕様書やコードに落とす。 (可観測性のためのコードが仕様書に載っていなかったり...)
ただし、すべてをフォローする必要もない。明らかな無駄は積極的に省く。
© ZOZO, Inc. 9 すこしずつリプレイスするために 2 漸進的な適用方法を考える。 ビッグバンリライトをしない、という話の延長線。 • コンポーネントレベルでの適用:
「フッターのみ」など • ページ(URL)単位での適用: 「/privacy のみ」など いかに小さく始められるかを常に考える。
© ZOZO, Inc. 10 すこしずつリプレイスするために 2 WEARでは、CDN(Fastly)を置きパスルーターにした。 実装+テストが完了したページから順次切り替え。
© ZOZO, Inc. 11 開発者体験に投資する。 CI/CD、静的解析(TypeScript, ESLint)、テスト、自動化。 すべてを最初から100点にする必要はないが、60点を切らないように常に改善。 あくまでも投資なので、すぐに結果がでなくても良い。 すこしずつリプレイスするために
3
© ZOZO, Inc. 12 • リプレイスは既存のコードを変形するだけで済む箇所もあるので、 変形のためのスクリプトを用意する ◦ 万人に役立つスクリプトじゃ無くていい ◦
リプレイスのためのものはそうそう都合よく公開されていない • リンターでは拾いきれないコーディングルールを明文化する ◦ カスタムルールをサッと書けるならそうする すこしずつリプレイスするために 3
© ZOZO, Inc. 13 負債にしないために 1 プロダクトのコードは、その瞬間だけでも自分の中での100点を追求する。 コードは知らないうちに劣化し減点されていく。 ライブラリには脆弱性が見つかり、新しいAPIが追加される。 人間は常にアップデートされて、コード自体変わっていなくても100点に見えな
くなる。 数年前に自分が書いたコードを見て、なにもわからなくなる。
© ZOZO, Inc. 14 負債にしないために 1 「来た時よりも綺麗に」を意識し、劣化が目立つところは適宜改善を重ねる。 (ただし機能追加とリファクタリングの変更は分ける) 命名には最大限の注意を払う。命の名前。名は体を表す。 AIに聞くもよし、著名なライブラリを参考にするもよし。
WEARチームでは輪読会も有効だった。 • 良いコード/悪いコードで学ぶ設計入門 • Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考 • HTML解体新書-仕様から紐解く本格入門
© ZOZO, Inc. 15 負債にしないために 2 ライブラリは極力最新に追従し続ける。 ひとつひとつの差分は小さくても「塵も積もれば山となる」ので、 まとめてやったほうが楽などということはない。 WEAR
WebチームではRenovateのPRごとにランダムでメンバーがアサインされ 基本一週間以内に確認・マージ・リリースまで行う。 ライブラリに対するアンテナとしても機能する。
© ZOZO, Inc. 16 負債にしないために 3 腐敗防止層(ACL)を意識する。 DDDを導入しましょうでは無く、 特にライブラリを差し替えられるように意識する。 例えば日付のフォーマット。Intlの実装状況でライブラリが不要になるかも。
© ZOZO, Inc. 17 負債にしないために 4 フットワークの軽さを確保する。 リリースの頻度が少ないと、リリースの変更が大きくなる。 →変更箇所が多いと、バグを埋め込んだ時に原因が特定しづらくなる →原因が特定しづらいと、変更を恐れるようになる
変更はこまめにリリース、異変を見つけたらすぐに引き返す。 機能フラグ(フィーチャーフラグ)を積極的に活用して、 開発途中の機能でも非公開でリリースするなど。
© ZOZO, Inc. 18 負債にしないために 4 フットワークの軽さを確保する。 そのために、タスクの粒度を細かくする。 IssueやPull Requestを細かくすることで変更内容を把握しやすくする。
レビュー負担軽減により開発速度の向上にもつながる。 ただし、細かすぎは前後関係が途切れるので注意が必要。 やりながらラインを見極める。
© ZOZO, Inc. 19 もし「PHPやRuby on Railsを剥がしてReactにしたいです」と言われたら? ここまで確認してきたように、 1. 旧環境に敬意を持つ
(過信は禁物) 2. 少しずつ確実に進める(必要に応じ並行して機能開発もする) 3. 開発の基礎を守る リプレイスをすることになったら
© ZOZO, Inc. 20 全てを一度に良くすることはできないので、一歩ずつ確実にコトを進めましょう リプレイスじゃなくても
None