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

　　近三个月，我在测试一个基于Linux内核的容器化项目时，发现团队里两个刚毕业的新人——一个学Java的，一个搞前端的——居然能通过直接阅读内核代码解决资源调度冲突的问题。他们没看过《Linux内核设计与实现》，也没翻过官方文档，全靠啃git仓库里的提交记录和代码注释——这让我突然想起Linus Torvalds那句“好的代码本身就是最好的文档”。

　　2023年Linux 6.6版本发布时，有个关于eBPF的改进提交特别有意思：Linus在合并请求里只写了“fix the stupid race condition”（修复那个愚蠢的竞态条件），没有长篇大论的技术说明，但代码里用原子操作和内存屏障的组合，直接把问题场景的测试用例覆盖率从72%怼到了99%。我当时用ftrace跟踪了三天，发现这个修改影响的不仅是eBPF本身，连用户态的bpftool工具链都跟着自动适配了——这种“牵一发而动全身”的代码示范，比任何文档都直观。

文章配图，仅供参考

　　我主观判断：Linus的模式最适合“新技术”的传播。比如去年Rust for Linux项目刚启动时，核心开发者直接在代码里用Rust重写了部分内存管理模块，没有单独写设计文档，但通过git历史和代码中的TODO注释，全球开发者在三个月内就提交了超过200个优化补丁——这种“边写边教”的方式，比先写文档再实现，能更快验证技术可行性。毕竟文档会过时，但代码里的每一个提交记录都是实时更新的“活教材”。

　　不过，这种方法对测试工程师不太友好——我测试Linux网络栈时，经常遇到“这段代码为什么这样写？”的疑问，只能去邮件列表翻Linus二十年前的讨论记录（他居然还保留着1996年的邮件存档）。有时候真希望他能多写点注释——但转念一想，如果所有细节都写明白了，可能就少了那种“自己悟出来”的成就感？

　　下一步我打算做个实验：用Linus的方式教新人写测试用例——不写测试规范文档，直接让他们看我在git里的提交记录，特别是那些被驳回的“buggy commit”和对应的修复代码。看看三个月后，他们能不能像那两个新人一样，通过代码“自学成才”。

（编辑：草根网）

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