世界を動かす技術を、日本語で。

25M行のコードベースを一晩でフォーマットする

2026年5月5日原文(stripe.dev)

概要

この記事は、 Striperubyfmt プロジェクトにより、 2,500万行 のコードベースを一晩で自動整形した事例を紹介。 開発者生産性向上のための 技術的課題解決策 を解説。 rubyfmtの導入背景や、 大規模リファクタリング の手法を説明。 Stripeの エンジニアリング文化品質管理 の取り組みも取り上げる。 エンジニアやテクニカルライターによる 実践知見 を共有。

25ミリオン行のコードベースを一晩で整形:rubyfmtの舞台裏

  • Stripeの Developer Productivityチーム による大規模コード整形プロジェクト

  • 対象は 25,000,000行 に及ぶ巨大なRubyコードベース

  • コードの一貫性維持と 開発効率向上 を目的とした自動フォーマッタ rubyfmt の導入

  • プロジェクトリーダーは Fable Tales、テクニカルライターは Anna Mason

  • 一晩で全コードを自動整形するための インフラ設計運用ノウハウ

    • CI/CDパイプラインの拡張と 並列処理 による高速化
    • フォーマット前後の 差分検証 と自動テストによる品質担保
    • 開発者への 周知徹底 とドキュメント整備
  • 大規模リファクタリングに伴う 課題解決アプローチ

    • レガシーコードや独自記法への対応
    • フォーマットによる動作変更リスクの最小化
    • チーム横断での 合意形成 とルール策定
  • Stripeの エンジニアリング文化

    • 継続的改善(Continuous Improvement)の実践
    • コード品質開発速度 の両立
    • オープンな情報共有と ナレッジベース の構築
  • rubyfmt導入による 効果

    • コードレビュー負担の軽減
    • 新規開発・保守作業の効率化
    • 全社的な コーディングスタイル統一
  • 開発者向け追加リソース

    • Stripe Developers 公式YouTubeチャンネル
    • 開発者向けドキュメントとガイド
    • Stripe Discordサーバーや Developer Meetup によるコミュニティ支援

関連事例紹介

  • Selective Test Execution による50M行規模のテスト効率化
    • 必要なテストのみ実行することでCIの高速化を実現
  • Stripe CLIを使った 開発スタック自動構築
    • ホスティングやデータベース、AIツールの即時プロビジョニング

Stripeの情報・リソース

  • 公式ドキュメントや開発者向けガイドの活用推奨
  • YouTube、Twitter/X、Discordなどの公式SNSでの情報発信
  • 各地の Developer Meetup での最新情報共有とネットワーキング

著者情報

  • Fable Tales:StripeのDeveloper Productivity担当エンジニア
  • Anna Mason:Stripeのテクニカルライター、全社横断で執筆活動

Hackerたちの意見

25M行のコードにはビックリだよ!一つのコードベースにそんなに膨大な量があるなんて、全然想像できない。もっと詳しく知りたいな。

そうだね、残りのコードはどこにあるの?

記事によると、今は4200万行になってるみたいだよ。

たったの2500万行? :) Googleは10年前には数十億行あったのに… https://research.google/pubs/why-google-stores-billions-of-l...

うちの会社(Stripeよりはずっと小さいけど)は、今や450万以上になってるよ。グラフは完全に指数関数的だね。AIはここで大きな問題になってる。コードの量が爆発的に増えてるし、生成されるコードの質はまた別の話だね。

「一夜にして」っていう部分に驚いてる。Chromiumのソースでclang-formatを実行してみたんだけど(68,281の.ccファイル、wcによると2100万行):$ find chromium-149.0.7826.1/ -name ".cc" -exec cat {} + | wc 21640925 55715244 833460441 これが2014年のE5-2696 v3で6分もかからなかったよ:$ time find chromium-149.0.7826.1/ -name *.cc | parallel -j 16 clang-format $x>/dev/null real 0m5.666s user 1m13.964s sys 0m13.373s これは桁違いに速いね。特に、彼らが自分のワークロードを俺のようなポテトで動かしてないと仮定すれば。Rubyの構文ってC++よりそんなに複雑なの?それともツールの問題なのかな?

私の勘違いでなければ、モノレポだね。だから、25M LoCが単一のアプリにあるわけじゃなくて、彼らのサーバーサイドコードと共有ライブラリの(すべて?)が含まれているんだ。他にもいろんな言語が使われているよ。16年と何千人ものエンジニアがたくさんのコードを書くんだから。

swagger、protobuf、sqlcなどから生成されたたくさんのモデルやスタブを想像してみて。

浮いてるスパイラルのやつ、めっちゃ気が散って、記事を読むよりもInspectorでそれを消すのに時間かかっちゃった。読者を嫌ってるんじゃないかって思うくらい、ひどいよね。

prefers-reduced-motion: reduceを設定すれば、消えるよ。

初めての仕事は、小さなソフトウェア会社で、少数のクライアント向けにソフトを作ってたんだ。MS Basic PDSでね。リード開発者がコードのフォーマットを気にしないタイプで、だから「makenice」ってツールを作って、彼のぐちゃぐちゃなコードを見やすく整形したんだ。そしたら、彼はめっちゃ怒って、オフィスの前でぐるぐる回ってたよ。それで「makenasty」ってツールも作って、彼が好むスタイルにフォーマットするようにしたんだ。makenasty/niceはチームの数人にだけ共有したけど、みんな喜んでくれた。読みやすいものとリーダーが好きなものの間で簡単に変換できたからね。彼はmakenastyのことを全く知らなかったよ。

名前の問題を除けば、開発者の快適さのためにこれを行うのは全く理にかなったことだし、通常は簡単な変換で実現できるよ。手動で追加したインデントやスペースの調整などの制限があることが多いけど、どんな変更を許可するかをしっかり考えて、言語をよく理解していれば、非常に安全な操作になることができる。

Hacker Newsで議論の続きを見る