Hacker News 中文摘要

RSS订阅

一夜格式化2500万行代码库 -- Formatting a 25M-line codebase overnight

文章摘要

Stripe工程师开发了Ruby自动格式化工具rubyfmt,解决了全球最大Ruby代码库的格式化难题。该项目源于2018年RubyConf会议后的讨论,经过6年开发,最终成功在一夜之间格式化2500万行代码,实现了零配置、快速格式化的目标,填补了Ruby生态的空白。

文章总结

标题:一夜之间格式化2500万行代码库:rubyfmt的故事

核心内容:

  1. 项目背景
    Stripe拥有全球最大的Ruby代码库(2500万行),此前行业缺乏真正的Ruby自动格式化工具。2018年,作者在RubyConf的一场讨论后,开始开发开源项目rubyfmt,目标是打造一个零配置、高效且对非Ruby工程师友好的格式化工具。

  2. 设计原则

    • 零配置:避免像rubocop因可配置性引发的团队争议,借鉴gofmt的强制统一风格。
    • 极致速度:将格式化耗时严格限制在100毫秒内,为此直接编译C程序链接libruby,绕过常规Ruby启动和bundler的延迟。
    • 跨语言友好:帮助非Ruby背景工程师快速适应,消除代码格式不确定性。
  3. 技术挑战与实现

    • 早期原型:基于Ruby内置的ripper解析器,但性能不足。
    • Rust重写:为提升速度,改用Rust实现,但需解决Ruby对象与Rust的交互问题,最终通过直接操作Ruby内存结构绕过JSON序列化瓶颈。
    • Prism迁移:2025年转向官方新解析器Prism,脱离Ruby VM依赖,显著减少二进制体积并提速。
  4. Stripe的规模化落地

    • 渐进式部署:初期按文件逐个启用,通过差异对比工具和测试确保正确性。
    • 全库格式化:2024年某个周六,一次性格式化全库,避免合并冲突,最终覆盖4200万行代码。
    • 效果反馈:工程师不再争论格式问题,新成员尤其受益,开发效率显著提升。
  5. 开源与协作
    项目始终保持开源,Stripe投入全职工程师支持,前员工Reese等贡献者持续参与开发。

精简后的关键细节:

  • 性能数据:常规Ruby启动需158毫秒,bundler环境达345毫秒,而rubyfmt控制在100毫秒内。
  • 技术亮点:Rust通过serde反序列化Ruby的ripper输出,后改为直接操作VALUE类型内存结构。
  • 影响:格式化后代码库的PR摩擦减少,工程师反馈“无需再思考格式问题”。

删除的次要内容:

  • 具体酒吧对话细节、早期原型代码片段(如switch语句)、部分技术实现调试过程(如JSON序列化性能问题)。
  • 个别工程师的匿名评价重复内容。

评论总结

以下是评论内容的总结,平衡呈现不同观点并保留关键引用:

  1. 对Ruby用于金融系统的担忧

    • 观点:对大型金融公司使用Ruby处理资金系统表示不安。
    • 引用:
      "A major financial processing company writes it money handling systems in Ruby. Terrifying."
      "Terrifying."
  2. 对代码规模的震惊与疑问

    • 观点:对2500万行代码的规模感到难以置信,并质疑代码是否无类型。
    • 引用:
      "I’m shocked at the 25M line part! That is a completely unfathomable amount of code for one codebase."
      "are those 45M LoC are untyped ?"
  3. 对代码格式化的讨论

    • 观点:
      • 支持格式化工具的重要性,分享个人经历(如makenice工具)。
      • 质疑AI时代是否需要人类可读的代码格式。
    • 引用:
      "I wrote a tool called makenice to format his nasty spaghetti gibberish into something with good indents."
      "Why bother formatting 25m lines of slop, and why is AI wasting tokens on making code look human-readable anyway?"
  4. 逐步引入格式化工具的建议

    • 观点:推荐渐进式引入格式化工具以避免冲突,而非一次性全量格式化。
    • 引用:
      "I always did it incrementally via a script that reformatted all files that are not touched in any open PR."
      "The initial run reformatted 95% of all files."
  5. 格式化工具的安全性与设计原则

    • 观点:强调格式化工具应确保仅修改空格,并优先处理复杂语法。
    • 引用:
      "It walks through the unformatted and formatted strings in parallel skipping any whitespace."
      "tackle the hardest syntax first and the rest will follow."
  6. 对代码与数据规模的反思

    • 观点:代码规模相对数据较小,工具化潜力大。
    • 引用:
      "code as text is tiny... you can invent some pretty amazing tooling."
  7. 对UI设计的批评

    • 观点:文章中的浮动元素干扰阅读体验。
    • 引用:
      "The floating spiral thing is so distracting... I feel like they hate their readers."
  8. 对投入时间优化格式的调侃

    • 观点:调侃投入大量时间调整格式的奢侈。
    • 引用:
      "Man must me nice to have the time to put so much work into tabs."