云风的 BLOG: 为什么说不要编写庞大的程序

《Unix 编程艺术》中总结的 Unix 哲学中有这么一条：除非确无它法，不要编写庞大的程序。并且在第 13 章花了一章讨论复杂度的问题。（第 13 章复杂度：尽可能简单，单别简单过了头）

下周一，是我们项目的一个进度线。所以，周末我安排了加班。当然，我最近两年，每个休息日都给自己安排的加班，无所谓周末。不过给团队安排加班还是比较稀少的事情。

由于种种原因，不是每个人都能够把自己的休息时间贡献出来的。作为团队负责人，我的原则是，生活大于工作。如果有生活上的事情，就可以拒绝加班。对于项目，也不应该把某件事情依赖到特别的某个人身上，虽然某些东西由特定的人去做（比如维护自己写的模块/程序）会效率高一些，但是其他人也应当可以顶替。

所以，偶尔维护一下不是自己写的代码，且能够在很短时间进入状态，就是团队每个人应该具有的能力。在这方面，我们的团队做的还不是很好，不是每个人都有这样的能力。但、这也并非个人能力单方面的因素。

同样，光靠提升代码质量也不是能完全解决问题的。整个项目的模块切分、文档定义等等更为重要。

说起来，我的感触就是：”除非确无它法，不要编写庞大的程序“ 。简洁小巧的程序总是好维护的。尤其是容易进入状态的。我说的进入状态即：在出现 bug 的 30 分钟内可以弄明白那些不是自己写的、陌生的没有读过的代码的脉络。并且开始着手解决问题。

强调进入状态的速度，是因为，如果需要去读几个小时的代码才摸清楚结构的话，还不如等到下个工作日，让原作者给你解释或由原作者去解决问题。

其实，不仅仅是这个周末。已经有太多周末以及夜晚，办公室里人员不齐，遇到问题必须自己解决了。虽然不是所有问题都可以自己弄明白，偶尔也需要打电话给相关代码的作者问清楚。但是，大部分问题都还是可以搞定的。我觉得很大程度上，就是因为，我们从来没有编写庞大的程序，即使是迫不得以编写庞大的程序（比如游戏的 client ），也把层次和模块分的很清晰，每个都不大。

最后想说的是：不要把问题推给别人。即便不是为自己的项目工作，作为程序员，发现问题就应该着手考虑解决。这也是开源的精神（当然，使用闭源软件就很难做到了）。作为程序员，解决问题，是自身能力提高的源泉。

有时，修补他人的代码，甚至是不被你的美学所接受的代码，更能增强对代码的把握能力。比如：我放弃用 C++ 编写软件，但我不排斥阅读 C++ 项目。即便我一边用嘲讽的语气去评论那些“精巧的”设计，另一方面也会客观的去理解是什么需求导致了如此的结构。

最近，工作太忙。没时间看书。只是把《Unix 编程艺术》放在手边，累了就翻一下。其实呢，许多道理本就明白，可每次看见白纸黑字，还是觉得的确很有道理。最近一年，觉得自己悟了许多。悟：并非明白了以前不明白的东西.知识还是那些知识，道理还是那些道理，似乎没有学到新的，又胜过学了新的东西。

一则有趣的对比：

我们的项目在 Windows 下，使用 mingw make 全部需要 47 秒（很干净的 Windows XP ，没有装任何杀毒软件）。

但是在 freeBSD 上用同样的机器，做同样的事情只用 18 秒。

谁可以解释这个差异？

因为 Windows 开进程太慢？文件系统太糟糕？Console 速度太慢？mingw 的 gcc 太慢？

Comments

在另一篇文章下留言提示了一段错误信息，百度又追踪到了这篇文章，浏览的过程中不小心发现了答案 ~ 我填的也是中文七。。阴吹思婷

Posted by: 文生 | (59) July 29, 2016 01:30 AM

人气好哇

Posted by: 股票行情 | (58) May 23, 2009 03:42 AM

gcc在win32平台上是不支持预编译的.当然要慢得多.虽然也可以生成预编译文件,但实际上没什么作用.. 当然,win32的文件系统本身就不适合unix下那种有点BT的用法..

Posted by: xx | (57) May 12, 2009 02:37 PM

游戏软件相对于很多系统软件来说只能算小软件??这个说法很搞笑哦，很幽默

Posted by: ajivacat | (56) May 12, 2009 01:23 PM

一直不清楚，云风现在做的项目，一点信息也没有透露出来，包括云风，包括网易，呵呵，其实这样也不好，可能当初立项时候，觉得很先进，但是时间在变化，看看现在国外的产品，尤其是NCSoft的产品，已经不再是那个吴下阿蒙了，没别的意思，给云风提个醒，做事情要适当的抬头看看周遭比较好。

Posted by: zzz | (55) May 2, 2009 12:50 PM

程序员一定要合作。

Posted by: fuwu | (54) May 1, 2009 12:51 PM

在开发过程中所追求的与一般用户所追求的，还是有差异的……

Posted by: Dim | (53) May 1, 2009 02:45 AM

现在对写程序已经有恐惧感了，

Posted by: 平台租用 | (52) April 30, 2009 02:05 PM

关于游戏本身的内容，什么时候透露一下下呀

Posted by: Jim | (51) April 29, 2009 02:46 PM

到了某种境界，一定要悟！

Posted by: summer | (50) April 28, 2009 10:32 AM

我同意15楼关于从木结构到钢结构，从三叶虫变猴子一样，是自然过程这样的说法，总的来说，要看需要解决的问题，有的问题，比如说像linux操作系统内核，为了效率原因，没有使用微内核的方法就是一个“大块”程序，更进一步讲，使用简单的电路来组建模拟真实三叶虫是可以的，然而人类一直以来试图也用这样的方式来认识甚至模拟建造我们的大脑，我们看到了成功的曙光了吗？

Posted by: heighgun | (49) April 24, 2009 05:37 PM

好啊

Posted by: lily | (48) April 24, 2009 11:30 AM

Posted by: lily | (47) April 24, 2009 11:29 AM

继续关注你的博客。 HOHO

Posted by: 草榴 | (46) April 23, 2009 08:02 PM

"...MinGW aims to provide native functionality and performance via direct Windows API calls...." 所以mingw某种程度上说，是一个仿真器。而GCC在unix/linux下面，gcc静态库libgcc.a，kernel，libc一般都实现了处理器级优化的。另外，我一直坚信unix文件系统的buffer和cache性能从来都是领先于window的。两个证据：1.window从dos文件系统诞生到nt的微内核技术，一直是跟着unix学的；2.服务器系统从来都是unix的天下，文件系统性能是关键指标，而大型工程编译过程对FS系统的buffer&cache是个很好的经验。我觉得基本上是这两个原因，做下benchmarking，内核&文件系统差异很快就能得到量化的参考值。

Posted by: LFB | (45) April 23, 2009 07:17 PM

XP用mingw编译好比linux跑wine慢。阿菠萝13号里用全用登月舱当救生艇一样－－系统设计的是为其特定目标优化的，现在出现新的目标，简单的改造当然效率不会太高。xp是为多线程应用优化的，linux是为多进程编程优化的。

Posted by: 哥俩好 | (44) April 23, 2009 10:20 AM

博主是个敬业的人，这一点导至博主也是一个敬佩的人。

Posted by: 哥俩好 | (43) April 23, 2009 10:12 AM

Simple is best!

Posted by: David | (42) April 23, 2009 04:47 AM

我认同文章中的观点。 1. 别人如果30分钟看不懂你程序结构(指能力相近的人)，你自己可能过一阵也看不懂。 2. 项目越来越大的时候，这一块会成为隐患。

Posted by: Tim | (41) April 22, 2009 11:05 PM

我喜欢kiss，但是现实中的确不可能做到程序员想要的kiss,社会上程序员还是少数

Posted by: fnsoxt | (40) April 22, 2009 09:35 PM

很多年前就看见过云风这个名字，不记得是在哪里了，好像是《电软》？印象里，还聊过几句来着。最近才翻到你的blog，最近一直在看见你说忙。既然生活大于工作，是不是该调剂一下了？总觉得你一直是这样，写代码，写代码，不停写代码。这样不太好，会很累的。

Posted by: Br | (39) April 22, 2009 07:58 PM

很多关于windows的问题看了《windows编程启示录》之后都会恍然大悟：为什么微软要这么做？说到底，windows商业化得多，使用者整体的电脑水平参差不齐，涉及到的硬件厂商更多，所以微软需要考虑的问题也更多更复杂。我并非为微软辩解，只是想说，其实很多事情看待的角度不同会导致有不同的结果。微软考虑问题的时候性能基本不会是第一因素，因为，慢一点不见得会导致客户的抱怨，如果出现错误，即使问题出在客户自己的软件或者硬件，受到抱怨的也往往是微软。

Posted by: loveour | (38) April 22, 2009 09:10 AM

因为 Windows 开进程太慢？文件系统太糟糕？Console 速度太慢？mingw 的 gcc 太慢？个人觉得，更多的是商业和学术之间的差异。商业的成功，就是要追求利润，多少的成本，带来多少的收益。对于M$而言，他们的程序员应该不差FreeBSD那样的技术能力，但他们更多的在意投入的成本，至少出来的结果嘛，够用就行，能赚到钱就OK。所以，他们并不会太过追求运行效率。而对于FreeBSD这种更技术、更学术的东西，商业利益的地位远在技术之下，所以BSD的程序员们，能够写出更优秀的程序。 //一直潜水学习云风BLOG，终于忍不住也冒个泡泡

Posted by: ER1C | (37) April 21, 2009 04:51 PM

我们公司也在大量用cygwin编译，在linux上编译明显快很多。我个人试验过，在文件系统上差的最多。可以把mingw的编译盘用放到虚拟的内存上会快很多。

Posted by: toorq | (36) April 21, 2009 04:10 PM

貌似《Unix 编程艺术》也给几种复杂度分了类.

Posted by: 123 | (35) April 21, 2009 12:48 PM

强大的人类，mark...

Posted by: firendless | (34) April 21, 2009 01:09 AM

据说铱星打电话必须在室外、不能有明显的遮挡……这样的效果他们自己也不会好意思说先进吧……

Posted by: sjinny | (33) April 20, 2009 10:22 PM

虽然不知道云风做的是什么项目，但从以前的博文中隐约看的出是一个很有前瞻性的东西。不过这种东西的风险也比较大，尤其是当它是由技术专家主导而不是用户主导的时候。铱星就是这样一个项目，它的技术是绝对领先的，但用户呢？不了解情况，瞎说一通，见笑了，呵呵。

Posted by: limantian | (32) April 20, 2009 09:34 PM

office，也许它*必须*以统一的风格集成到一个界面上，但这不代表这个界面背后的事情*必须*都在同一个程序里完成。多个后台功能进程+一个前台界面进程也是可能的，所以即使是office，也不一定就必然是庞大的单个程序。

Posted by: sjinny | (31) April 20, 2009 08:19 PM

大家都争争，无伤大雅，有时自己跟同事争论一些观点，也会面红耳赤。不过，我还是倾向于大家只是就观点而论。 mm的话也算不上个人崇拜，大概是女孩子吧，比较直率，呵呵。像我这样半路因为接触云风的文章便喜欢上他，可见写文章、聊天，以云风的这种温和、沉稳的方式，显然更容易让人接受，甚至喜爱。

Posted by: chinainvent | (30) April 20, 2009 06:38 PM

to all: 个人觉的用一种开发原则解决所有开发问题和架构设计问题是不现实的。

Posted by: sunway | (29) April 20, 2009 04:36 PM

analyst和云风是多年的朋友，也是我的前同事，他没有恶意，提出的问题也是比较现实的问题，很多时候在用户需求面前要放弃一些开发的原则是比较正常的事情。软件开发界是没有银弹的，kiss原则也不可能通用任意开发场合。

Posted by: sunway | (28) April 20, 2009 04:34 PM

@all 互相探讨聊个天如果我有啥语气不好得罪了大家，大家多担待我，不是我本意的，呵呵。

Posted by: kxjiron | (27) April 20, 2009 04:04 PM

@dyou analyst 应该和博主是老朋友了吧，老朋友用这种语气有啥奇怪的。我只是不喜欢有人搞个人崇拜主义。了解得越多，发现自己懂得越少。为了更好的解决问题，人们不停的尝试、寻找、思考、优化，但是除了上帝没有人知道最优的答案。最多可以逼近最优的答案。云风编码追求很严格要求自己我们是知道的，是不是应该人人都模仿呢？追求自我突破比简单模仿好阿。 Office很复杂，做游戏的如果违背编码美学，还可以和策划商量。office这种软件呢？谁愿意和你妥协需求的？细想下其中的细节代码量，各个关系，简直就是剪不断理还乱。做过几十万行代码，慢慢就会明白kiss很重要，但是现实毕竟复杂，复杂到你得妥协和折中，有时放弃一些kiss也许也很重要。

Posted by: kxjiron | (26) April 20, 2009 04:02 PM

kxjiron: analyst的语气似乎不懂得尊重人，你也认同？

Posted by: dyou | (25) April 20, 2009 03:08 PM

哈哈，恕我直言。analyst 的观点并没有什么错，也没有恶意，却被云风的fans攻击，这就是个人崇拜带来的盲从。

Posted by: kxjiron | (24) April 20, 2009 01:37 PM

呵呵！不要编写庞大复杂的程序，其含义也应该包括尽量让模块高内聚低偶合吧！喜欢读云风的文章，感觉就像读《游戏编程精粹》中某些精彩文章似的。云风兄有空多写啊：）

Posted by: RAINSSA | (23) April 20, 2009 11:21 AM

我个人认为是pipe的原因导致了编译速度的差别. 我写了个VI插件, 在LINUX下和在WINDOWS下的速度差别很大很大, 其中最最明显的差别处就在于当调用外部命令执行管道重定向时.

Posted by: kevinlei | (22) April 20, 2009 11:17 AM

代码大不大其行数和结构复杂度不是决定因素。Google要搜索的信息够大够复杂吧，可只需要几秒钟就能找到需要的内容。可惜的是不能只用几秒钟去更新相应内容。

Posted by: 赵中 | (21) April 20, 2009 10:53 AM

通常windows下涉及进程间通信的事，都要比unix下慢。比如编译工具通常会使用的pipe。

Posted by: mouse | (20) April 20, 2009 10:02 AM

终于知道原因了，那个验证，我填了中文“七”，一直被那个报错信息误导... 改一改呀，老大。

Posted by: chinainvent | (19) April 20, 2009 09:13 AM

不知为啥，有时想发个言，老出错，今天再再试试。 In an effort to curb malicious comment posting by abusive users, I've enabled a feature that requires a weblog commenter to wait a short amount of time before being able to post again. Please try to post your comment again in a short while. Thanks for your patience. 我已经等了很久鸟...

Posted by: 发不了言？ | (18) April 20, 2009 09:11 AM

对于analyst ：我想对你说几句话，mm我对云风关注的时间不算少了，而你对云风的态度始终是在拆台。难道你很牛b是不是。按照我的估计，就算你很牛b，但是你的态度就让很多人受不了，我想在生活中你肯定比不上云风，云风几乎是人见人爱，而你高傲的性格可能是不得人缘。我说的没错吧。

Posted by: mm | (17) April 20, 2009 12:30 AM

"时间都花在cygwin的wrapper上，最简单的i/o调用都要跑到里面绕一大圈，速度能快就怪了相比之下，colinux速度快了很多倍" MinGW gcc和cygwin gcc不一会是吧

Posted by: zhangyafeikimi | (16) April 19, 2009 09:58 PM

unix提倡搭积木，充分利用管道，进程，ipc。windows这这些方面是在是太弱了，创建进程的代价很大。gcc也慢的让人急啊。

Posted by: zhangyafeikimi | (15) April 19, 2009 09:56 PM

程序不庞大不复杂是不可能的从控制台到gui，就好像是平房到楼房，从木结构到钢结构，从三叶虫变猴子一样，是自然过程说不要编写庞大的程序那是逆天的说法，不现实可单独编译，可独立测试的模块不要设计得太大才是正确的追求

Posted by: black | (14) April 19, 2009 09:54 PM

我觉得程序复杂是指程序逻辑的庞大，人脑暂时存放的东西非常少，超过这个限制就很容易犯错了。

Posted by: netawater | (13) April 19, 2009 09:44 PM

其实这里的庞大是以一个独立的程序为单位的，这些程序仍然可能组成为一个庞大的系统。不过我更感兴趣的是如何评判是否过于庞大。也许是判断一个程序是否做了完全可以独立出去的事情？