Unix基本哲学

 3. 组合原则：设计时考虑拼接组合。

    4. 分离原则：策略同机制分离，接口同引擎分离。

    5. 简洁原则：设计要简洁，复杂度能低则低。

    6. 吝啬原则：除非确无它法，不要编写庞大的程序。

    7. 透明性原则：设计要可见，以便审查和调试。

    8. 健壮原则：健壮源于透明与简洁。

    9. 表示原则：把知识叠入数据以求逻辑质朴而健壮。

    10. 通俗原则：接口设计避免标新立异。

    11. 缄默原则：如果一个程序没什么好说的，就沉默。

    12. 补救原则：出现异常时，马上退出并给出足够错误信息。

    13. 经济原则：宁花机器一分，不花程序员一秒。

    14. 生成原则：避免手工hack，尽量编写程序去生成程序。

    15. 优化原则：雕琢前先要有原型，跑之前先学会走。

    16. 多样原则：决不相信所谓“不二法门”的断言。

    17. 扩展原则：设计着眼未来，未来总比预想来得快。

    如果刚开始接触Unix，这些原则值得好好体味一番。谈软件工程的文章常常会推荐大部分的这些原则，但是大多数其它操作系统缺乏恰当的工具和传统将

    这些准则付诸实践，所以，多数的程序员还不能自始至终地贯彻这些原则。蹩脚的工具、糟糕的设计、过度的劳作和臃肿的代码对他们已经是家常便饭了；他们奇

    怪，Unix的玩家有什么好烦的呢。

    1.6.1 模块原则：使用简洁的接口拼合简单的部件

    正如Brian Kernighan曾经说过的：“计算机编程的本质就是控制复杂度”[Kernighan-Plauger]。排错占用了大部分的开发时间，弄出一个拿得出手的可用系统，通常与其说出自才华横溢的设计成果，还不如说是跌跌撞撞的结果。

    汇编语言、编译语言、流程图、过程化编程、结构化编程、所谓的人工智能、第四代编程语言、面向对象、以及软件开发的方法论，不计其数的解决之道被抛

    售者吹得神乎其神。但实际上这些都用处不大，原因恰恰在于它们“成功”地将程序的复杂度提升到了人脑几乎不能处理的地步。就像Fred

    Brooks的一句名言[Brooks]：没有万能药。

    要编制复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度——用清晰的接口把若干简单的模块组合成一个复杂软件。如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至牵动全身。

    1.6.2 清晰原则: 清晰胜于机巧

    维护如此重要而成本如此高昂；在写程序时，要想到你不是写给执行代码的计算机看的，而是给人——将来阅读维护源码的人，包括你自己——看的。

    在Unix传统中，这个建议不仅意味着代码注释。良好的Unix实践同样信奉在选择

    算法和实现时就应该考虑到将来的可扩展性。而为了取得程序一丁点的性能提升就大幅度增加技术的复杂性和晦涩性，这个买卖做不得——这不仅仅是因为复杂的代码容易滋生bug，也因为它会使日后的阅读和维护工作更加艰难。

    相反，优雅而清晰的代码不仅不容易崩溃——而且更易于让后来的修改者立刻理解。这点非常重要，尤其是说不