董昊 http://rdc.taobao.com/blog/cs/?p=147

最近参与一个大项目，几十个开发人员，代码都放在一个 trunk 下，也就是说，这几十个人的代码都在一起编译，一起跑单元测试，一起在半夜跑自动化测试用例。反正我以前是从未加入过这么大的 trunk（之前我参加的项目最多就四五个人在一起写代码而已），现在发现巨大的 trunk 造成了一些很郁闷的问题。

首先，编译越来越慢。项目用 scons 来编译（我暂时还没发现 scons 比 Makefile 好在哪里），一编译就耗干系统的内存（我们的系统是 8G 内存），整个 trunk 重编译一次是两个多小时，好在我负责的只是其中一部分，但是即使是这一部分，也要花十多分钟编译（我目前还不能说这是 scons 慢造成的，但是 python 占内存偏多，嫌疑很大），这在我调试阶段很费时间。

其次，互相干扰很严重。几十个程序员，就算一个人每一个月才出现一次代码错误，那加起来就是：每天都有人至少犯一次代码错误。虽然使用了 ReviewBoard，但是 review 不可能洞察一切，还是会有单元测试频繁的不过。后来加了一个提交代码的工具，为每个提交代码的人单独编译并跑单元测试，通过了才真正交给 subversion，但这样还是有问题：每次提交，我都发现有很多人排着队的等前面的人编译完，我有几次好不容易排上了，跟别人的提交一起编译，结果由于别人的提交编译不过，我还得重新排队……问题的根源在于：这个 trunk 上的提交太过频繁了。毕竟几十个人呢，几乎每十分钟就有新的 code 需要提交。

可能长期在互联网公司干，我对那种动辄几百万行 code，几十兆可执行文件的大软件越来越反感。我觉得好的软件，一定是满足且刚好满足了某一类用户的某一个需要，而不是妄图去满足所有用户的很多需要。说白了：尽量做小巧的东西。如果项目真的是个大项目，那最好是能拆成多个小软件，好歹代码能分到不同的 trunk 下去，trunk 小了，挤在一个 trunk 下的开发人员就会少很多，就不会有漫长的编译和频繁的提交了，然后，这些小软件一起运行，完成某个大工作。

说得有点理想化了，把大项目拆成小部分，这个道理谁都懂，但难度在于怎么拆？这种问题我回答不了，也许《unix 编程艺术》能够回答：不要写一个巨大的进程，应该写多个，然后一起工作。进程都可以拆开，代码有什么不能拆开的？有人可能担心效率，但是相比于混乱的管理，这点效率损失我觉得还算值得。

以上是我的看法。实际中，反例也是有的，比如 windows NT 就是一堆人挤在一个代码 trunk 下做出来的，而且产品还很成功。但是从《观止》里可以看出，NT 的开发人员也一样被频繁的 build break 和单元测试 fail 折磨得人不人鬼不鬼，也许这就是为什么他们要辛苦上 6 年才能开发完成，以及为什么操作系统的未来是属于微内核的（微内核巧妙的把 OS 拆开了）