Linus亲述：不写文档，如何用代码领导千万开发者

文章配图，仅供参考

Linus的"代码即文档"哲学有个关键前提——代码必须足够"锋利"。比如Linux内核的RCU（Read-Copy-Update）机制，2002年首次提交时，代码里只有三行注释："This is RCU. It's magic. Don't touch." 但配套的测试用例却写了2000多行，覆盖了从单核到32核的所有场景。开发者们不是靠文档理解RCU，而是通过跑测试、看提交历史、甚至直接给Linus发补丁来学习——这种"用代码说话"的方式，反而让核心机制20年来几乎没变过，而同期其他操作系统的类似机制，光文档就迭代了7个版本。

我实测过这种模式的威力：去年在服务网格里推新协议时，按传统方式写了50页设计文档，结果开发团队看了两周还在问"这个字段到底什么意思"。后来我学Linus，直接把协议实现拆成三个独立模块，每个模块的接口只有3个方法，测试用例覆盖了所有边界条件——团队两天就搞定了，甚至有个实习生自己写了兼容旧版本的补丁。新技术之所以能快速普及，往往不是因为文档多，而是因为代码本身足够"自解释"——就像Linux的VFS层，30年来没变过抽象接口，但通过不断重构底层实现，支持了从ext4到ZFS的所有文件系统。

但这种模式也有翻车的时候。2018年Linux 4.15合并时，有个关于内存管理的补丁被Linus直接骂回去："你这代码写得像狗屎，连我都看不懂！" 后来发现，提交者为了"简洁"，把原本分开的内存分配和释放逻辑揉进了一个函数里，导致上下文切换时出现内存泄漏。Linus的暴脾气反而成了质量过滤器——如果代码连他都看不懂，那肯定有问题。这种"用代码质量代替文档"的方式，虽然粗暴，但确实筛选出了最核心的贡献者——Linux内核现在维持着每周1000+的补丁提交量，但核心维护者始终只有200人左右。

主观判断：Linus的模式适合"新技术"的爆发期，但不适合成熟期的维护。比如Linux内核现在超过3000万行代码，新功能开发确实不需要文档，但调试一个20年前的驱动问题，没有文档简直像在黑暗里摸墙——我上次排查一个2005年的SCSI驱动问题，花了三天才在邮件列表里找到当年开发者的一句"哦，这个寄存器要这样操作"。所以我的结论是：用代码领导开发者可以，但得配个"文档急救包"——至少把关键决策的上下文、历史背景、设计 trade-off 记下来，不然等原始开发者离职，代码就成了黑盒。

下一步行动：我准备在服务网格里试个"半Linus模式"——新功能开发时不写文档，但每个核心模块必须配一个"README.md"，只写三件事：1）这个模块解决什么问题；2）关键设计决策；3）如何测试。上周已经强制要求团队这样做了，目前看提交速度没降，但新人上手时间从两周缩短到了三天——看来Linus的哲学，得结合实际情况"本地化"才行。

（编辑：草根网）

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