为什么说不要编写庞大的程序
《Unix 编程艺术》中总结的 Unix 哲学中有这么一条：除非确无它法，不要编写庞大的程序。并且在第 13 章 花了一章讨论复杂度的问题。（第 13 章 复杂度：尽可能简单，单别简单过了头）
下周一，是我们项目的一个进度线。所以，周末我安排了加班。当然，我最近两年，每个休息日都给自己安排的加班，无所谓周末。不过给团队安排加班还是比较稀少的事情。
由于种种原因，不是每个人都能够把自己的休息时间贡献出来的。作为团队负责人，我的原则是，生活大于工作。如果有生活上的事情，就可以拒绝加班。对于项目，也不应该把某件事情依赖到特别的某个人身上，虽然某些东西由特定的人去做（比如维护自己写的模块/程序）会效率高一些，但是其他人也应当可以顶替。
所以，偶尔维护一下不是自己写的代码，且能够在很短时间进入状态，就是团队每个人应该具有的能力。在这方面，我们的团队做的还不是很好，不是每个人都有这样的能力。但、这也并非个人能力单方面的因素。
同样，光靠提升代码质量也不是能完全解决问题的。整个项目的模块切分、文档定义等等更为重要。
说起来，我的感触就是：”除非确无它法，不要编写庞大的程序“ 。简洁小巧的程序总是好维护的。尤其是容易进入状态的。我说的进入状态即：在出现 bug 的 30 分钟内可以弄明白那些不是自己写的、陌生的没有读过的代码的脉络。并且开始着手解决问题。
强调进入状态的速度，是因为，如果需要去读几个小时的代码才摸清楚结构的话，还不如等到下个工作日，让原作者给你解释或由原作者去解决问题。
其实，不仅仅是这个周末。已经有太多周末以及夜晚，办公室里人员不齐，遇到问题必须自己解决了。虽然不是所有问题都可以自己弄明白，偶尔也需要打电话给相关代码的作者问清楚。但是，大部分问题都还是可以搞定的。我觉得很大程度上，就是因为，我们从来没有编写庞大的程序，即使是迫不得以编写庞大的程序（比如游戏的 client ），也把层次和模块分的很清晰，每个都不大。
最后想说的是：不要把问题推给别人。即便不是为自己的项目工作，作为程序员，发现问题就应该着手考虑解决。这也是开源的精神（当然，使用闭源软件就很难做到了）。作为程序员，解决问题，是自身能力提高的源泉。
有时，修补他人的代码，甚至是不被你的美学所接受的代码，更能增强对代码的把握能力。比如：我放弃用 C++ 编写软件，但我不排斥阅读 C++ 项目。即便我一边用嘲讽的语气去评论那些“精巧的”设计，另一方面也会客观的去理解是什么需求导致了如此的结构。
最近，工作太忙。没时间看书。只是把《Unix 编程艺术》放在手边，累了就翻一下。其实呢，许多道理本就明白，可每次看见白纸黑字，还是觉得的确很有道理。最近一年，觉得自己悟了许多。悟：并非明白了以前不明白的东西.知识还是那些知识，道理还是那些道理，似乎没有学到新的，又胜过学了新的东西。
一则有趣的对比：
我们的项目在 Windows 下，使用 mingw make 全部需要 47 秒（很干净的 Windows XP ，没有装任何杀毒软件）。
但是在 freeBSD 上用同样的机器，做同样的事情只用 18 秒。
谁可以解释这个差异？
因为 Windows 开进程太慢？文件系统太糟糕？Console 速度太慢？mingw 的 gcc 太慢？
