Unix基本哲学

 Unix哲学起源于Ken Thompson早期关于如何设计一个服务接口简洁、小巧精干的操作系统的思考，随着Unix文化在学习如何尽可能发掘Thompson设计思想的过程中不断成长，同时一路上还从其它许多地方博采众长。

    Unix哲学说来不算是一种正规设计方法。它并不打算从计算机科学的理论高度来产生理论上完美的软件。那些毫无动力、松松垮垮而且薪水微薄的程序员们，能在短短期限内，如同神灵附体般造出稳定而新颖的软件——这只不过是经理人永远的梦呓罢了。

    Unix哲学（同其它工程领域的民间传统一样）是自下而上的，而不是自上而下的。Unix哲学注重实效，立足于丰富的经验。你不会在正规方法学和标

    准中找到它，它更接近于隐性的半本能的知识，即Unix文化所传播的专业经验。它鼓励那种分清轻重缓急的感觉，以及怀疑一切的态度，并鼓励你以幽默达观的

    态度对待这些。

    Unix管道的发明人、Unix传统的奠基人之一Doug McIlroy在[McIlroy78]中曾经说过：

    （i）让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。

    （ii）假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。

    （ⅲ）尽可能早地将设计和编译的软件投入试用, 哪怕是操作系统也不例外，理想情况下, 应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。

    （iv）优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事，必先利其器。

    后来他这样总结道（引自《Unix的四分之一世纪》（A Quarter Century of Unix [Salus]））：

    Unix哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。

    Rob Pike, 最伟大的C语言大师之一, 在《Notes on C Programming》中从另一个稍微不同的角度表述了Unix的哲学[Pike]：

    原则1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。

    原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。

    原则3：花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。

    原则4：花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。

    原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。

    原则6：没有原则6。

    Ken Thompson——Unix最初版本的设计者和实现者，禅宗偈语般地对Pike的原则4作了强调：

    拿不准就穷举。

    Unix哲学中更多的内容不是这些先哲们口头表述出来的，而是由他们所作的一切和Unix本身所作出的榜样体现出来的。从整体上来说，可以概括为以下几点：

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

    2. 清晰原则：清晰胜于机巧。