Unix哲学

跨平台可移植性和开放标准

Unix在不同种类的计算机、众多厂商、各种专用硬件上提供了一个一致的、文档齐全的应用程序接口（API）。
Unix API几乎可以作为编写真正可移植软件的硬件无关标准。

Internet和万维网

统一资源定位符URL(Uniform Resource Locator)作为Web的核心概念，也是Unix中无处不在的统一文件名字空间概念的泛化。

Unix哲学基础

Unix哲学起源于Ken Thompson早期关于如何设计一个服务接口简洁、小巧精干的操作系统的思考，随着Unix文化在学习如何尽可能发掘Thompson设计思想的过程中不断成长。

Unix哲学是自下而上的，Unix哲学注重实效，自足于丰富的经验。它鼓励那种分清轻重缓急的感觉，以及怀疑一切的态度，并鼓励以幽默达观的态度对待这些。

Doug Mcllroy—Unix管道的发明人、Unix传统的奠基人之一Doug Mcllroy

1. 让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。
2. 假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
3. 尽可能早地将设计和编译地软件投入试用，哪怕是操作系统也不例外，理想情况下，应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。
4. 优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事必先利其器。

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

Rob Pike—C语言大师

• 原则1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
• 原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
• 原则3：花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）
• 原则4：花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。
• 原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织底井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。
• 原则6：没有原则6。

Ken Thompson—Unix最初版本的设计者和实现者

禅宗偈语般对Pike的原则4作了强调：
拿不准就穷举

概括

1. 模块原则：使用简洁的接口拼合简单的部件。
2. 清晰原则：清晰胜于机巧。
3. 组合原则：设计时考虑拼接组合。
4. 分离原则：策略同机制分离，接口同引擎分离。
5. 简介原则：设计要简洁，复杂度能低则低。
6. 吝啬原则：除非却无它法，不要编写庞大的程序。
7. 透明性原则：设计要可见，以便审查和调试。
8. 健壮原则：健壮源于透明与简洁。
9. 表示原则：把知识叠入数据以求逻辑质朴而健壮。
10. 通俗原则:接口设计避免标新立异。
11. 缄默原则：如果一个程序没什么好说的，就沉默。
12. 补救原则：出现异常时，马上退出并给出足够错误信息。
13. 经济原则：宁花机器一分，不花程序员一秒。
14. 生成原则：避免手动hack，尽量编写程序去生成程序。
15. 优化原则：雕琢前先要有原型，跑之前先学会走。
16. 多样原则：决不相信所谓的“不二法门”断言。
17. 扩展原则：设计着眼未来，未来总比预想来的快。

1.模块原则

计算机编程的本质就是控制复杂度。要编制复杂软件，需要用清晰的接口把若干简单的模块组合成一个复杂软件。如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至于牵动全身。

2.清晰原则

• 良好的注释
• 选择算法和实现时应该考虑到未来的可扩展性

永远不要去吃力地解读一段晦涩的代码三次，第一次也许侥幸成功，但如果发现必须重新解读一遍——离第一次太久了，具体细节无从回想——那么你该注释代码了，这样第三次就相对不会那么痛苦了。——Henry Spencer

3.组合原则

在输入输出方面，Unix传统极力提倡采用简单、文本化、面向流、设备无关的格式。在经典的Unix下，多数程序都尽可能采用简单过滤器的形式，即将一个输入的简单文本流处理为一个简单的文本流输出。

在做一个GUI前，最好还是想想可不可以把复杂的交互程序跟干粗活的算法程序分离开，每个部分单独成为一块，每个部分单独成为一块，然后用一个简单的命令流或者时应用协议将其组合在一起。

在构思精巧的数据传输结构前，有必要实地考察一下，是否能利用简单的文本数据格式；以一点点格式解析的代价，换得可以使用通用工具来构造或解读数据流的好处是值得的。

4.分离原则

Unix哲学中的策略同机制分离与OOP思想中的问题空间和解空间的分离有何异同？
Unix哲学中，这条设计准则告诉我们应该设法将接口和引擎剥离开。

1. 实现这种剥离的一个方法是，比如，将应用按照一个库来编写，这个库包含许多有内嵌脚本语言驱动的C服务程序，以至于整个应用的控制流程则用脚本来撰写而不是用C语言。这种模式的经典例子就是Emacs编辑器，它使用内嵌的脚本语言Lisp解释器来控制用C编写的编辑原语操作。
2. 另一个方法是将应用程序分成可以协作的前端和后端进程，通过套接字上层的专用应用协议进行通讯。前端实现策略，后端实现机制。比起仅用单个进程的整体实现方式来说，这种双端设计方式大大降低了整体复杂度，bug有望减少，从而降低程序的寿命周期成本。
   tfrunning银行系统的老平台体现了第一种方法 而JAVA版本新平台体现了第二种方法

5.简洁原则

错综复杂的美妙事物听来自相矛盾。Unix程序员相互比的是谁能够做到“简洁而漂亮”并以此为荣，这一点虽然知识隐含在这些规则之中，但还是很值得公开提出来强调一下。——Doug Mcllroy

Unix编程哲学鼓励一种软件文化，以简洁为美，人人对庞大复杂的东西群起而攻之——这是一个非常看重简单解决方案的工程传统，总是设法将程序系统分解为几个能够协作的小部分，并本能地抵质任何用过多噱头来粉饰程序的企图。

6.吝啬原则

尽量不要编写 体积大||复杂程度高的程序

7.透明性原则

调试通常会占用四分之三甚至更多的开发时间（在日常开发中感受非常显著），一个特别有效的减少调试工作量的方法就是设计时充分考虑透明性和显见性。
透明性 一眼就能够看出软件是在做什么以及怎样做的。（编程时注意写注释）
显见性 程序带有监视和显示内部状态的功能。（在合适的地方输出日志）
==至少，调试选项的设置应该尽量不要在事后，而应该在设计之初便考虑进去。==这是考虑到程序不但应该能够展示其正确性，也应该能够把原开发者解决问题的思维模型告诉后来者。
程序如果要展示其正确性，应该使用足够简单的输入输出格式，这样才能保证很容易地检验有效输入和正确输出之间的关系是否正确。
还应当提倡接口简洁，以方便其它程序对其进行操作——尤其是测试监视工具和调试脚本。

8.健壮原则

在有异常输入的情况下，保证软件健壮性的一个非常重要的策略就是避免在代码中出现特例。bug通常隐藏在处理特例的代码以及处理不同特殊情况的交互操作的代码中。

9.表示原则

把知识叠入数据以求逻辑质朴而健壮
数据要比编程逻辑更容易驾驭。如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。更进一步：在设计中，应该主动将代码的复杂度转移到数据之中去。
此种考量并非Unix社区的原创，但是许多Unix代码都显示受其影响。特别是C语言对指针使用控制的功能，促进了在内核以上各个编码层次上对动态修改引用结构。在结构中用非常简单的指针操作就能够完成任务，在其它语言中，往往不得不用更复杂的过程才能完成。

10.通俗原则

接口设计避免标新立异
（最小惊奇原则）

最小立异原则的另一面是避免表面相似而实际缺略有不同。这会极端危险，因为表象相似往往导致人们产生错误的假定。所以最好让不同事物有明显区别，而不要看起来一模一样。

11.缄默原则

（体现在系统上下文context和数据总线database上）

我认为简洁是Unix程序的核心风格。一旦程序的输入成为另一个程序的输出，就很容易把需要的数据挑出来。站在人的角度上来说——重要信息不应该混杂在冗长的程序内部行为信息中。如果显示的信息都是重要的，那就不用找了。

12.补救原则

最坏的情况：补救措施没有成功，却悄无声息地埋下崩溃的隐患（及时声明），直到很久以后才显现出来，这就是最坏的一种情况。

13.经济原则

为什么在Unix哲学中提出这个原则，挂起等待解释

14.生成原则

避免手工hack，尽量编写程序去生成程序，同样的，为什么在Unix哲学中提出这个原则，这更像是更高级语言而不是C语言做的事
在各个层次上使用生成原则（有编译器、解释器的原因）。当代码生成器能够提升抽象度时——即当生成器的说明性语句要比生成码简单时，使用代码生成器会很合理。
在Unix传统中，人们大量使用代码生成器使易于出错的细节工作自动化。Parser/Lexer生成器就是其中的经典例子，而makefile生成器和GUI界面式的构建器（interface builder）则是新一代的例子。

15.优化原则

过早的局部优化会妨碍全局优化，先制造原型，再精雕细琢，优化之前先确保能用！！先求运行，再求正确，然后求快。
“快速原型化”“敏捷开发”

16.多样原则

开放、可扩展、用户定制
（用户比开发者更懂需求）

17.拓展原则

数据格式（XML）和代码留下拓展的空间

一言以蔽之

态度

• 追求卓越，思考的时后急急忙忙跑去编程、无情删繁就简。
• 珍惜时间不浪费，某人已经解决某个问题，直接拿来用，不要让骄傲和偏执拽住你重做一遍。善用工具，尽可能将一切都自动化。
• 艺术！