大道理讲过千百遍它依然是大道理，一点都不实际。比较实际的东西就是：Unix文化并没有什么高深完美的科学理论作为依托。它跟其他工程领域一样，植根于丰富的实践经验，是经过不断的总结和融合而逐步形成的。它是自下而上的，不是自上而下的，更注重于实用性。你很难在所谓正规的方法学或标准中找到它们。它属于那种出自于人们本能的隐性知识，换句话说就是所谓的专业经验。它鼓励那种分轻重缓急和怀疑一切的态度，并促使你以幽默达观的心态对待这些。 Unix管道的发明人、Unix传统的奠基人之一Doug McIlroy从某些侧面对Unix文化做了一些阐释： （1）让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。 （2）假定每个程序的输出都会成为另一个程序的输入，即便那个程序目前可能还不存在。输出中不要有不相关的信息出现，这会形成干扰。避免使用严格的分栏格式或二进制格式输入。尽量避免使用交互式输入。 （3）尽可能早地将设计和编译的软件投入试用，即使是操作系统也不例外，理想情况下，应该在几个星期内。拙劣的代码不值得珍惜，扔掉重写。 （4）优先使用工具而不是晦涩的帮助文档来减轻编程任务的负担。工欲善其事，必先利其器。 Rob Pike，最伟大的C语言大师之一，在Notes on Programming in C中则从编程的角度对Unix文化进行了阐释，这也反映了一些侧面： 原则1： 你无法判定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找地方改代码，除非你已经证明那儿就是瓶颈所在。 原则2： 估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。 原则3： 花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n很大，否则不要用花哨算法。即使n很大，也优先考虑原则2。 原则4： 花哨的算法比简单的算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。 原则5： 数据压倒一切。如果已经选择了正确的数据结构并把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。 原则6： 没有原则6。 这些或许还不够全面。于是，Eric S. Raymond大师，在他的著作《Unix编程艺术》一书中说道：“Unix哲学中更多的内容不是这些先哲们口头表述出来的，而是由他们所作的一切和Unix本身所做出的榜样体现出来的。”并且做了这样的总结： 模块原则：使用简单的接口拼合简单的部件。 清晰原则：清晰胜于机巧。 组合原则：设计时考虑拼接组合。 分离原则：策略同机制分离，接口同引擎分离。 简洁原则：设计要简洁，复杂度能低则低。 吝啬原则：除非确无它法，不要编写庞大的程序。 透明性原则：设计要可见，以便审查和调试。 健壮原则：健壮源于透明与简洁。 表示原则：把知识叠入数据以求逻辑质朴而健壮。 通俗原则：接口设计避免标新立异。 缄默原则：如果一个程序没什么好说的，就沉默。 补救原则：出现异常时，马上退出并给出足够的错误信息。 经济原则：宁化机器一分，不花程序员一秒。 生成原则：避免手工hack，尽量编写程序去生成程序。 优化原则：雕琢前先要有原型，跑之前先学会走。 多样原则：决不相信所谓“不二法门”的断言。 扩展原则：设计着眼未来，未来总比预想来得快。 一共17条原则，我喜欢称它们为“ESR的17条”，它涉及Unix文化的方方面面，可以说是事无巨细了。很多讲述软件工程的书籍或文章都会或多或少的提及若干，甚至大多数操作系统在设计和实现上也会或多或少的有所体现。但它们始终没能将这些原则自始至终的贯彻到底，从而也导致了大部分像我这样的苦逼程序员一直被蹩脚的工具、糟糕的设计、过度的劳作和臃肿的代码所困扰，而且还奇迹般地形成了习惯，总给人展现出那种“沃德田•诺•布雷斯•博苏富斯基” 的酷。
Linux就是这个范儿——4.7 这一切的基础大师的阐释
