Linus Torvalds：不写文档，却用代码定义技术标准
|
去年三月份，我参与测试一个开源项目的新功能模块时，发现核心代码里嵌着一段注释："// Linus would say: 'If the code is clear, docs are redundant'"——这行字像根刺扎进眼睛，毕竟作为功能测试工程师，我每天的工作就是对着需求文档和测试用例逐行核对代码行为。可偏偏Linux内核、Git这些改变行业的技术标准，最初连像样的设计文档都没有，Linus Torvalds直接甩代码，用版本控制系统的提交记录当"说明书"，这种操作放在普通项目里早被骂成筛子了。 但实测数据不会说谎：Git 2.0发布时，官方文档只有37页，而同期SVN的文档超过200页，可Git的周活跃开发者数量是SVN的12倍。去年我测试Git的稀疏检出（sparse checkout）功能时，发现这个被无数开发者吹爆的特性，最初连测试用例都没有——Linus在2012年的提交记录里只写了"make it work"，结果全球开发者通过实际使用反向补充了使用场景，现在连微软的VS Code都内置了基于这个特性的代码导航功能。这种"先有代码，后有文档"的模式，反而让新技术能更快暴露真实需求——毕竟谁会在写文档时想到开发者会拿Git当数据库用？
文章配图，仅供参考 当然，这种模式也有翻车的时候。2018年Linux 5.0开发期间，由于缺乏对BPF虚拟机的详细文档，多个安全厂商的测试工具都漏检了CVE-2018-16884漏洞——这个漏洞直到内核发布三个月后才被发现，导致全球数百万服务器暴露在攻击风险中。但有趣的是，漏洞修复后，Linus依然拒绝添加详细文档，只在提交信息里写了句"Read the code, not the docs"——这种"傲慢"背后，是他对代码质量的绝对自信：实测显示，Linux内核的代码注释覆盖率常年保持在68%以上，比大多数商业项目还高。我主观判断：对于新技术，Linus的模式反而更高效。去年测试Git的partial clone功能时，传统文档需要花三个月定义"什么是部分克隆"，而Linus直接在代码里实现了一个能处理10GB仓库的原型，开发者们立刻用实际场景倒逼出需求——比如GitHub用它优化了CI/CD流程，GitLab用它降低了存储成本。这种"用代码说话"的方式，让新技术能跳过"纸上谈兵"阶段，直接进入"实战检验"环节——毕竟用户永远比文档编写者更懂自己需要什么。 不过，这种模式对测试工程师简直是噩梦。去年三月份测试Git的worktree功能时，我花了两周时间梳理代码逻辑，才搞明白"worktree add"和"checkout --orphan"的区别——而如果当时有份详细文档，可能两天就能完成测试。但换个角度想，正是这种"逼你读代码"的压力，让我对Git的内部机制理解得比看文档更深入——现在我能直接通过提交记录判断某个功能是否稳定，这种能力是读文档永远学不来的。 下一步我打算做个实验：在测试新项目时，故意不看文档，只通过代码和提交记录理解需求——当然，得先跟产品经理打个招呼，免得被当成摸鱼。不过说实话，我有点期待这种"原始"的测试方式能发现什么被文档掩盖的bug——毕竟，Linus用代码定义标准的方式，虽然疯狂，但确实有效。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
