Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ソースコードが何年残るか計測してみた-どこをリファクタリングすべきかを定量的に分析する

Avatar for ebi ebi
September 05, 2026

 ソースコードが何年残るか計測してみた-どこをリファクタリングすべきかを定量的に分析する

XP祭り2026 LT の資料です

Avatar for ebi

ebi

September 05, 2026

More Decks by ebi

Other Decks in Programming

Transcript

  1. 自己紹介 • ebihara99999 • だいたいのアカウントこれでやってます。 • Anoka Partners株式会社 代表 •

    受託開発・外部CTO・技術顧問の会社をやっています • 近況 • XP祭り初参加!よろしくお願いします • 奥歯が折れてしまい差し歯ができるまで歯無しです。歯は 大事に…(持ち帰って欲しいメッセージ)
  2. なぜ計測したか • リポジトリマイニング・振る舞い分析が好きで、いろいろ試して いる。AI 時代、出力が多くレビューや品質保証が大変な今こそ、 役に立つ分析があるはずという仮説を持っている(AIのおかげで 分析も楽) • Claude Code

    と議論する中で、コードの寿命を観察する分析(以 下、半減期分析)を知った • 半減期分析によって「どこをリファクタリングすべきか」定量的 に計測できる可能性がある
  3. どう計測したか 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
  4. レイヤーごとの半減期 ディレクトリごとの半減期。単位は年。 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 年
  5. 計測方法による結果の違い • ここまでの結果を検証した結果、本家と異なる計測方法で計測 していたことが判明 • 「コードの半減期」の本家は Erik Bernhardsson, "The half-life

    of code & the ship of Theseus"(2016-12-05) • 本家のツール git-of-theseus を mastodon に使用しリポジトリ 全体を計測した • 結果は 2.2 年 —— 先述の計測方法では 4.5 年 • 何が異なるのだろう
  6. 本家の計測方法(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 に実行しその出力から作成
  7. 計測方法の比較 誰の 計測方法 Erik 私 意味 行ごとに生まれた日と 今日書いた 1 行があと何年

    消えた日を追う(gitもつか of-theseus) 任意の範囲に、その日あっ 毎年 1 月 1 日のコード たコードが半分に減るまで × 8 月 28 日の HEAD 何年か(リポジトリ全体で の blame も、ディレクトリでも) 答え 2.2 年 4.5 年 私の計測方法では「いつ書かれたか」の観点が漏れていた。2016年に書かれ 2020年に残っていたコードも、2020年に書かれたコードも同じに扱った。
  8. 結果の解釈とリファクタリング判断への示唆 結果 • 私の計測方法では、レイヤーごとに寿命の差が出た • 一般的に、長寿命の場所ほどリファクタリングの価値がある • Erik の計測方法では未計測だが、同じように差が観察できる前提とすると—— 使いどころ

    • 私の計測方法(簡便法): 既存コード全体を眺めて、どこからリファクタリン グするか当たりを付けるときに使える • Erik の計測方法(標準): 上記に加え、今書いているコードに「もう少し手を かけるべきか?」の目安にも使える 次の一手 • 今回は LT なのでレイヤーで導出したが、ファイルごとに見ると複雑なコード ベースの残存期間が長いコアドメインが炙り出せるかも?(change coupling なども併用すると良いだろう。)
  9. 参考文献 • 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