我对UNIX的理解

 1994年，X Window系统开发组的成员Mike Gancarz根据他自己的Unix系统经验以及和其他领域使用Unix系统的资深程序员们的讨论结果，写成了《The UNIX Philosophy》，提出了9条训格之言：

一：小即是美。

二：让程序只做好一件事。

三：尽可能早地建立原型。

四：可移植性比效率更重要。

五：数据应该保存为文本文件。

六：尽可能地榨取软件的全部价值。

七：使用shell脚本来提高效率和可移植性。

八：避免使用可定制性低下的用户界面。

九：所有程序都是数据的过滤器。

此外还有十条原则则并不为所有人认同，甚至还是争论的焦点（如宏内核和微内核之争）：
一：应该允许用户定制操作环境。

二：让操作系统核心小而轻。

三：使用小写字母并尽量简短。

四：节约纸张，保护树林。

五：沉默是金。

六：并行地思考。

七：部分加部分大于整体。

八：寻找问题的帕雷托法则。

九：程序随需求而增长（Worse is better）。

十：层级地思考。

罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的，但作为Unix哲学丝毫不为过：

• 规则一：你永远不会知道你的程序会在什么地方耗费时间。程序的瓶颈常常出现在意想不到的地方，因此在你确信找到瓶颈后再动手优化代码吧。
• 规则二：测试代码。只有在你详细测试了代码，并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。
• 规则三：功能全面的算法（fancy algorithm）在处理小规模问题时效率很低，这是因为算法时间效率中的常量很大，而问题往往规模很小。除非你知道你遇到的常常是复杂的情况，否则就让代码丑陋但是简单而高效吧。（即使问题规模确实很大，也首先尝试第二条规则。）
• 规则四：功能全面的算法比简单的算法更容易产生Bug，更难实现。尽量使用简单的算法和数据结构。
• 规则五：数据决定一切。如果选择的数据结构能很好的管理数据，算法部分往往不言自明。记住，数据结构，而非算法，才是编程的关键。
• 规则六：没有第六条规则。