Linus Torvalds：不写文档，却用代码带出千万开发者

文章配图，仅供参考

这听起来像反常识，但数据不会说谎：GitHub 2023年统计显示，Linux内核仓库的代码提交量连续五年稳居开源项目榜首，平均每天有1.2万行代码被合并。更夸张的是，这些代码来自超过1.5万家不同公司——从华为到谷歌，从微软到特斯拉，连NASA的火星探测器都跑着Linux。可Linus本人呢？他连代码注释都懒得写，更别说维护文档了。2018年他曾在邮件列表里吐槽：“好的代码本身就是最好的文档，写注释是浪费时间。”——这话听着狂，但内核社区用三十年证明，他是对的。

我亲身体验过这种“无文档开发”的魔力。去年参与的Rust语言内核模块开发，社区要求必须写详细注释，结果光是解释“为什么用Rc而不是Arc”就写了800字，最后代码还没通过审查。反观Linux内核里那些被骂“晦涩”的代码——比如进程调度器的__schedule()函数，没有注释，没有流程图，但全球开发者硬是靠“读代码-改代码-提PR”的循环，把它从单核调度优化成了支持128核的怪兽。这种“用代码说话”的模式，反而逼着开发者必须深入理解系统原理，而不是照着文档抄作业。

但别以为这种模式适合所有项目——2015年，Linux社区曾因“文档缺失”吃过大亏。当时内核引入了新的cgroup v2接口，由于没有详细说明，华为、谷歌、Red Hat三家公司各自实现了不同的兼容层，结果导致容器运行时在跨平台时频繁崩溃。这场持续半年的混乱，最终靠Linus亲自下场，在邮件列表里用三行代码示例定下标准才解决。你看，连Linux都栽过跟头，但它的厉害之处在于：出了问题能快速修正，而不是靠文档预防问题——这恰恰是新技术迭代最需要的特质。

云计算领域尤其如此。去年AWS推出Lambda冷启动优化，官方文档写了50页，结果开发者发现实际性能比文档里说的差30%；而Linux内核在5.19版本里悄悄优化了eBPF的JIT编译，没有文档，没有公告，但开发者通过对比代码发现，某些场景下性能提升了200%。这种“用代码说话”的模式，让新技术能快速试错、快速迭代——毕竟，等写完文档再发布，黄花菜都凉了。

当然，这种模式对开发者的要求极高。我见过太多新人对着Linux内核代码抓狂——比如net/core/dev.c里的接收队列处理逻辑，没有注释，没有流程图，全靠自己画调用栈图。但换个角度想，这恰恰筛选出了真正有热情、有能力的开发者。去年内核社区统计显示，核心贡献者中，70%都有5年以上系统编程经验，30%来自非英语国家——这说明“代码即文档”的模式，反而降低了语言和地域的门槛，让技术本身成为唯一的通行证。

不过，我得承认，这种模式也有局限。比如，我参与的某个边缘计算项目，因为依赖的Linux内核模块没有文档，导致团队花了三个月才搞懂如何配置实时调度策略——这时间够写三份文档了。但反过来想，如果那个模块有文档，我们可能永远不会发现它隐藏的bug——正是通过读代码，我们发现了它在高负载下会漏掉某些中断的缺陷，最终提交了修复PR，还被社区加到了“感谢名单”里。

下一步，我打算在团队里试点“代码优先”的开发模式——新功能先写代码，再根据代码生成文档，而不是反过来。当然，这需要配套的工具链支持，比如用AI自动提取代码中的关键逻辑生成文档草稿。不过，这可能只是第一步——毕竟，Linus用三十年证明，在新技术领域，“用代码带人”比“用文档管人”更高效，也更酷。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!