为什么说不要编写庞大的程序



本文从一篇转载文章说起，该文章其中一个话题我认为很有现实意义：论述了为什么不要编写庞大的程序；另外，文章抛出了一个问题：同样的项目，为什么在windows上编译比在freeBSD要慢很多很多呢？

看了这篇文章，结合自身的经历，在文章后面也谈谈自己的感受。欢迎探讨。

为什么说不要编写庞大的程序？

注：以下段落内容转自：http://blog.codingnow.com/2009/04/ieaeeoaooaeio.html

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

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

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

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

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

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

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

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

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

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

---

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

---

一则有趣的对比：

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

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

谁可以解释这个差异？

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

读后感（原创）

说说自己对“为什么不要编写庞大的程序”的感受。就这个话题，看完上面的论述，我理解其意为：我们应该尽量编写简洁小巧的、容易维护的程序。

看到上面内容之前几个小时，在21IC BBS上看到一篇文章帖子——《论技术的极致》，链接：http://bbs.21ic.com/icview-604773-1-1.html。这篇文章也描述了一个现象：很多技术人员喜好挑战高难度，追求技术上的极致和完美。

自己而言，感同身受。在做系统的事情，在编写程序的时候，一个现象就是：尽展所学、绞尽脑汁让自己编写的程序表现的多么高深、多么的技巧、多么的玄美；功能上极尽地想做到最大兼容、预留强大的扩展性。而往往这样做下来的结果是：

1. 舍本琢末，忽略需求的本质；
2. 简单问题复杂化，工作强度加大累得自己半死。
3. 代码冗余，不易维护。

为什么这么说呢？

比如说一个功能模块，它本来需求是管理3种在功能和性能上有一些差异的芯片（基本功能相同，某一硬件板只用其中一种）。为使软件代码统一、方便维护和管理、而且设计时想当然认为是不是要预留第4种芯片的管理，因此，设计为屏蔽这3种芯片的差异向上层提供统一的API接口，结果弄了个中间层，一堆结构体和函数指针。

屏蔽差异力求统一，本来初衷是好的。但问题是，这些芯片本身就具有较大差异，强行统一必然导致整个模块实现的复杂化，而且还想当然有第4种芯片，则有可能留下多余的代码和信息。这种情况是，如果是设计者本身维护可能问题不大，然换成其他人来维护呢？其他人不得不花费不少精力来理清这个复杂的设计架构，期间可能还会被设计者留下多余的代码和信息搞得云里雾里。

所以，作为一名程序员，一切的程序设计应该从最本质的需求出发，回归自然，而不是刻意地炫耀你的编程水平。

第2个话题：同样的项目，为什么在windows上编译比在freeBSD要慢很多很多呢？

我觉得如果你对这个问题有兴趣，不妨去看看那文章的评论。我摘录一些自已认为比较有用的评论在这里。

“…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，内核&文件系统差异很快就能得到量化的参考值。

个人觉得，更多的是商业和学术之间的差异。商业的成功，就是要追求利润，多少的成本，带来多少的收益。

对于M$而言，他们的程序员应该不差FreeBSD那样的技术能力，但他们更多的在意投入的成本，至少出来的结果嘛，够用就行，能赚到钱就OK。所以，他们并不会太过追求运行效率。

而对于FreeBSD这种更技术、更学术的东西，商业利益的地位远在技术之下，所以BSD的程序员们，能够写出更优秀的程序。

我个人认为是pipe的原因导致了编译速度的差别.

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

更多的自己去看了，看别人的观点，吸取精华，去其真伪，这也是一个自我提高、自我积累的过程。