$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実際にリビルドを完遂してみて
Search
takayuki.miura
June 28, 2022
Technology
0
790
実際にリビルドを完遂してみて
takayuki.miura
June 28, 2022
Tweet
Share
More Decks by takayuki.miura
See All by takayuki.miura
TerraformをやめてCDKでReStartしたあと、 CDKをやめてCDK for TerraformでReStartした話
tmiura0203
0
1.6k
急激なDB書き込みが行われるサービスをリビルドした話
tmiura0203
0
830
Spring Bootという強すぎるフレームワークについて
tmiura0203
0
1.1k
Other Decks in Technology
See All in Technology
RAG/Agent開発のアップデートまとめ
taka0709
0
140
【pmconf2025】PdMの「責任感」がチームを弱くする?「分業型」から全員がユーザー価値に本気で向き合う「共創型開発チーム」への変遷
toshimasa012345
0
270
AWS re:Invent 2025で見たGrafana最新機能の紹介
hamadakoji
0
120
今からでも間に合う!速習Devin入門とその活用方法
ismk
1
430
SSO方式とJumpアカウント方式の比較と設計方針
yuobayashi
7
490
「Managed Instances」と「durable functions」で広がるAWS Lambdaのユースケース
lamaglama39
0
260
Playwright x GitHub Actionsで実現する「レビューしやすい」E2Eテストレポート
kinosuke01
0
330
Lambdaの常識はどう変わる?!re:Invent 2025 before after
iwatatomoya
0
290
世界最速級 memcached 互換サーバー作った
yasukata
0
330
re:Invent 2025 ふりかえり 生成AI版
takaakikakei
1
170
A Compass of Thought: Guiding the Future of Test Automation ( #jassttokai25 , #jassttokai )
teyamagu
PRO
1
240
“決まらない”NSM設計への処方箋 〜ビットキーにおける現実的な指標デザイン事例〜 / A Prescription for "Stuck" NSM Design: Bitkey’s Practical Case Study
bitkey
PRO
1
580
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.1k
Balancing Empowerment & Direction
lara
5
790
Designing for humans not robots
tammielis
254
26k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
The Pragmatic Product Professional
lauravandoore
37
7.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
The Cost Of JavaScript in 2023
addyosmani
55
9.3k
YesSQL, Process and Tooling at Scale
rocio
174
15k
The Language of Interfaces
destraynor
162
25k
Faster Mobile Websites
deanohume
310
31k
Transcript
実際にリビルドを完遂し てみて エキサイト株式会社 三浦大幸
自己紹介 三浦大幸 エキサイト株式会社 2016年入社 技術スタック - バックエンド(PHP・Java等) - フロントエンド(Vue等) -
インフラ(AWS) - アプリ(iOS) https://twitter.com/miura0203
アジェンダ 実際に1年かけて行ったリビルドの、経験と知見を共有し ます - リビルドの目的 - リビルド内容 - リビルドによる効果予測 -
実際にリビルドを行ったことによる効果 - 大変だったこと - リビルドの効果をより長持ちさせていくには
リビルドの目的
リビルドの目的 - 担当サービス:ウーマンエキサイト - とても古いサービス - 確認できるだけでも、最終コミットは 2010年
None
リビルドの目的 コードがあたかもゴミ屋敷 - 使われていない大量のコード - 1ファイルが長大 - いくつものif分岐が存在する共通メソッド - 謎アーキテクチャ
などなど…
リビルドの目的 ゴミ屋敷だと… - 普段やらないことをしようとすると、何がどこにあるかわからない - 物の位置がすぐに変わってどこにあるかわからなくなる - 新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる -
新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる → 発展的な開発が難しい
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる → 発展的な開発が難しい でも、これからはガンガン開発していきたい …
リビルドの目的 掃除することで、以下の達成が期待できる - 普段触っていないものでも、どこにあるかすぐに分かる - 物の位置がちゃんと決められており、失くしにくい - 新しい入居者が、すぐに生活を始められる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる → 発展的な開発がしやすくなる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる → 発展的な開発がしやすくなる ガンガン開発できる!
リビルド内容
リビルド内容 時間の問題もあり、今回は特に使用されている API2つに絞って リビルド - 言語・フレームワーク - PHP + Bear.Saturday
→ Java + Spring Boot - Webサーバ - Apache → Nginx - アーキテクチャ - 謎アーキテクチャ → クリーンアーキテクチャ - インフラ - EC2 → ECS(コンテナ化) - キャッシュシステム - ローカルファイル → Redis - その他 - 不要なコードの削除 - 複雑なコードのリファクタリング
リビルドによる効果予測
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる
リビルドによる 効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング
- アーキテクチャの改善
リビルドによる 効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング
- アーキテクチャの改善 - 希望的観測 - 必要なコンテナスペック減少 - 言語やフレームワークの変更
実際にリビルドを行ったことによる効果
実際にリビルドを行ったこ とによる効果 - コード量 1 /4 (ついでにユニットテストも追加)
実際にリビルドを行ったこ とによる効果 - コード量 1 /4 (ついでにユニットテストも追加) → 削減量はともかく、減ったことは想定通り
実際にリビルドを行ったこ とによる効果 - ネットワーク通信量 1 / 2 - サーバ(コンテナ)台数 1
/ 3 (スペック単位で計算) - レスポンスタイム 1 / 4
実際にリビルドを行ったこ とによる効果 - ネットワーク通信量 1 / 2 → 不要なレスポンスの削除と、 Nginxにして圧縮されるよう
になったから? - サーバ(コンテナ)台数 1 / 3 (スペック単位で計算) → 言語・フレームワークの変更による? - レスポンスタイム 1 / 4 → 言語・フレームワークの変更と、キャッシュを Redisにした ことによる?
実際にリビルドを行ったこ とによる効果 目的は主にコード量の削減やアーキテクチャ の変更等で、それ以外の改善は希望的観測 だったが、想定以上に改善された
大変だったこと
大変だったこと 時間がかかった 最初はAPI2つだけなので、3ヶ月から長くて半年程度で終わると 思っていたが、最終的にまるまる 1年かかった。 ずっとリビルドをやり続けることが大変だったのはもちろん、リビ ルドは完了してリリースして初めて成果として現れるので、周り への申し訳無さもあった。
大変だったこと どうしてもAPIの入出力は変えられない部分が多 いため、合わせる必要がある リビルド対象が限定されていたため、リクエスト・レスポンスデー タは大きく変えることができなかった。 加えて、本来APIでやらなくてもいいはずの処理だったとしても、 場合によってはそのまま APIでやる必要があったりした。
大変だったこと 使われている部分と使われていない部分の選定 使われていない部分は削除することも目的の 1つだったため、 APIの各エンドポイントの使用箇所とそのリクエスト・レスポンス データ、及びレスポンスデータの使いみちをすべて特定し、使わ れていない部分を削除した。
大変だったこと DBへの接続方法やキャッシュシステムの違い リビルド後はDB接続時にコネクションプールを使うようになった り、キャッシュシステムがファイルから Redisになったことで、考慮 すべき点が増えた。
リビルドの効果をより長持ちさせていく には
リビルドの効果をより長持ちさせていくには どんなにきれいに掃除しても、その後住人がまた汚く使っていてはいずれゴミ屋敷に 戻ってしまう。 リビルドも同様で、その時どんなに綺麗に作り直しても、その後考えて開発していかな いと、やがてまた汚いコードに戻ってしまう。 リビルドの効果をより長持ちさせていくには、 - エンジニアが、可読性や変更容易性を意識して開発していく ことが大事
ちゃんと掃除しよう!