Unix哲学 A Quarter Century of Unix，Notes on Programming in C，Mike
Mike Gancarz的《UNIX哲学》[编辑]
1994年，X窗口系统开发组的成员Mike Gancarz根据他自己的Unix系统经验以及和其他领域使用Unix系统的资深程序员们的讨论结果，写成了The UNIX Philosophy，提出了9条训格之言：
小即是美。
让程序只做好一件事。
尽可能早地创建原型。
可移植性比效率更重要。
数据应该保存为文本文件。
尽可能地榨取软件的全部价值。
使用shell脚本来提高效率和可移植性。
避免使用可定制性低下的用户界面。
所有程序都是数据的过滤器。
此外还有十条原则则并不为所有人认同，甚至还是争论的焦点（如宏内核和微内核之争）：
应该允许用户定制操作环境。
让操作系统核心小而轻。
使用小写字母并尽量简短。
节约纸张，保护树林。
沉默是金。
并行地思考。
部分加部分大于整体。
寻找问题的帕雷托法则。
程序随需求而增长（更糟就是更好）。
层级地思考。
Unix哲学是一套基于Unix操作系统顶级开发者们的经验提出的软件开发的准则和哲学。
UNIX 哲学由 Doug McIlroy 在1978年的《Bell System Technical Journal 》中发表:[1]
McIlroy：A Quarter Century of Unix[编辑]
道格拉斯·麦克罗伊是Unix系统上管道机制的发明者，也是Unix文化的缔造者之一。他归纳的Unix哲学如下：
程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流，因为这是一个通用的接口。
更加简化的版本是：做一件事，做好它。虽然只有第三条是特指Unix系统的，但Unix开发者们常常同时强调这三个信条。
Pike：Notes on Programming in C[编辑]
罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的，但作为Unix哲学丝毫不为过：
你永远不会知道你的程序会在什么地方耗费时间。程序的瓶颈常常出现在意想不到的地方，因此在你确信找到瓶颈后再动手优化代码吧。
测试代码。只有在你详细测试了代码，并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。
功能全面的算法（fancy algorithm）在处理小规模问题时效率很低，这是因为算法时间效率中的常量很大，而问题往往规模很小。除非你知道你遇到的常常是复杂的情况，否则就让代码丑陋但是简单而高效吧。（即使问题规模确实很大，也首先尝试第二条规则。）
功能全面的算法比简单的算法更容易产生bug，更难实现。尽量使用简单的算法和数据结构。
数据决定一切。如果选择的数据结构能很好的管理数据，算法部分往往不言自明。记住，数据结构，而非算法，才是编程的关键。
没有第六条规则。
Pike的第一、二条规则重申了高德纳的著名格言：“过早的优化是一切罪恶的根源。”[2] Pike的第三、四条规则被肯·汤普逊改述成：“疑惑不定之时最适合穷举。”事实上，这两条规则也是KISS原则的具体表现。规则五在之前Fred Brooks的人月神话中也被提及。Jon Bentley的《Programming Pearls》中也有一章阐述了相同的设计哲学。此规则作为“如果你的数据结构很好，那么控制它的算法就无关痛痒了”的例子常常被简化成“简约地写代码，聪明地用数据”。第六条规则当然只是Pike针对蒙提·派森之小品Bruces sketch的幽默发挥而已了。
