Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ソースコードが何年残るか計測してみた-どこをリファクタリングすべきかを定量的に分析する
Search
ebi
September 05, 2026
Programming
74
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ソースコードが何年残るか計測してみた-どこをリファクタリングすべきかを定量的に分析する
XP祭り2026 LT の資料です
ebi
September 05, 2026
More Decks by ebi
See All by ebi
Sorcery Internal Structure
ebihara99999
3
140
Sorcery Gem
ebihara99999
1
640
Other Decks in Programming
See All in Programming
PumaからFalconに移行したRailsアプリケーションでの実践
falcon8823
0
170
Workers Cache を知る
syumai
0
370
[Dev Group Paris Octobre 26] Agentforce, SIforce, Claudeforce, Slackbot… on s'y retrouve ?
nabondance
0
110
IBM Bob Dojo #1 仕様駆動開発入門
oniak3ibm
PRO
0
390
Rでドレミ/Do-Re-Mi_with_R
florets1
0
130
3回つくってわかった、 定期実行ジョブ基盤の本質情報
takai
0
500
AmebaブログはKMPから卒業します
kmars0605
0
200
re:Inventに行く前に知っておきたい現地参加のノウハウ
nokomoro3
0
430
The Rails Doctrine Decade
koic
2
590
AI主導のプログラミング学習アプリを作ってみた
econanringo
0
180
JIS keyboard support in Omarchy
lef237
0
120
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
160
Featured
See All Featured
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
600
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
20k
GitHub's CSS Performance
jonrohan
1033
470k
Un-Boring Meetings
codingconduct
0
460
It's Worth the Effort
3n
188
29k
The untapped power of vector embeddings
frankvandijk
2
1.9k
How STYLIGHT went responsive
nonsquared
100
6.3k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
4
4.4k
Being A Developer After 40
akosma
92
590k
Product Roadmaps are Hard
iamctodd
55
13k
New Earth Scene 8
popppiees
4
2.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
Transcript
ソースコードが何年残るか 計測してみた どこをリファクタリングすべきかを定量的に分析する XP祭り 2026 Anoka Partners株式会社 海老原佑介
自己紹介 • ebihara99999 • だいたいのアカウントこれでやってます。 • Anoka Partners株式会社 代表 •
受託開発・外部CTO・技術顧問の会社をやっています • 近況 • XP祭り初参加!よろしくお願いします • 奥歯が折れてしまい差し歯ができるまで歯無しです。歯は 大事に…(持ち帰って欲しいメッセージ)
なぜ計測したか • リポジトリマイニング・振る舞い分析が好きで、いろいろ試して いる。AI 時代、出力が多くレビューや品質保証が大変な今こそ、 役に立つ分析があるはずという仮説を持っている(AIのおかげで 分析も楽) • Claude Code
と議論する中で、コードの寿命を観察する分析(以 下、半減期分析)を知った • 半減期分析によって「どこをリファクタリングすべきか」定量的 に計測できる可能性がある
どう計測したか 1. ある年の1月1日時点のコードの行数を数える(例: 2020 年 → 116,181 行) 2. 調査日(2026年8月28日)の
HEAD で git blame を行い、2020 年 1月1日より前から変わっていない行を数える(→ 50,148 行) 3. ② ÷ ① = 2020年に存在するコードのうち今残っている割合 (→ 43%)。各年の1月1日で10年分繰り返し、50% を切る経過 年数を読む(→ 半減期 4.5 年) 対象: mastodon/mastodon ( 約 32 万行 ) 使用ツール: https://github.com/ebihara99999/xp_matsuri_20260905_lt
レイヤーごとの半減期 ディレクトリごとの半減期。単位は年。 8.0 年 app/models 7.9 年 app/controllers 7.1 年
app/services spec 4.0 年 app/views 3.8 年 app/javascript 2.4 年 app/javascript/mastodon/ の中を見ると(React, Redux) actions: 半減期なし reducers: 4.4 年 components: 3.3 年 features: 1.9 年
計測方法による結果の違い • ここまでの結果を検証した結果、本家と異なる計測方法で計測 していたことが判明 • 「コードの半減期」の本家は Erik Bernhardsson, "The half-life
of code & the ship of Theseus"(2016-12-05) • 本家のツール git-of-theseus を mastodon に使用しリポジトリ 全体を計測した • 結果は 2.2 年 —— 先述の計測方法では 4.5 年 • 何が異なるのだろう
本家の計測方法(git-of-theseus)が計測しているもの 書かれた 1 行が、生まれてから何年後に何割残っているか 1.0 残 っ て い 0.5
る 割 合 0.0 0.52 0.41 2.2 年で半分 0 1 2 3 4 5 6 7 8 生まれてからの年数 出典: git-of-theseus 0.3.4(Erik Bernhardsson)を mastodon/mastodon に実行しその出力から作成
計測方法の比較 誰の 計測方法 Erik 私 意味 行ごとに生まれた日と 今日書いた 1 行があと何年
消えた日を追う(gitもつか of-theseus) 任意の範囲に、その日あっ 毎年 1 月 1 日のコード たコードが半分に減るまで × 8 月 28 日の HEAD 何年か(リポジトリ全体で の blame も、ディレクトリでも) 答え 2.2 年 4.5 年 私の計測方法では「いつ書かれたか」の観点が漏れていた。2016年に書かれ 2020年に残っていたコードも、2020年に書かれたコードも同じに扱った。
結果の解釈とリファクタリング判断への示唆 結果 • 私の計測方法では、レイヤーごとに寿命の差が出た • 一般的に、長寿命の場所ほどリファクタリングの価値がある • Erik の計測方法では未計測だが、同じように差が観察できる前提とすると—— 使いどころ
• 私の計測方法(簡便法): 既存コード全体を眺めて、どこからリファクタリン グするか当たりを付けるときに使える • Erik の計測方法(標準): 上記に加え、今書いているコードに「もう少し手を かけるべきか?」の目安にも使える 次の一手 • 今回は LT なのでレイヤーで導出したが、ファイルごとに見ると複雑なコード ベースの残存期間が長いコアドメインが炙り出せるかも?(change coupling なども併用すると良いだろう。)
ご清聴ありがとうございました
参考文献 • Erik Bernhardsson, "The half-life of code & the
ship of Theseus"(2016-12-05) https://erikbern.com/2016/12/05/the-half-life-of-code.html • git-of-theseus(Bernhardsson のツール。生き残り曲線は Kaplan–Meier 法) https://github.com/erikbern/git-of-theseus • mastodon/mastodon(HEAD b59ddc79、調査日 2026-08-28) https://github.com/mastodon/mastodon • Martin Fowler, "Yagni"(2015-05-26) https://www.martinfowler.com/bliki/Yagni.html