Unix程序设计哲学

http://blog.chinaunix.net/uid-253939-id-2458682.html

 

1. Rule of Modularity: Write simple parts connected by clean interfaces.

2. Rule of Clarity: Clarity is better than cleverness.

3. Rule of Composition: Design programs to be connected to other programs.

4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

5. Rule of Simplicity: Design for simplicity; add complexity only where you must.

6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

7. Rule of Transparency: Design for visibility to make inspection and debugging easier.

8. Rule of Robustness: Robustness is the child of transparency and simplicity.

9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

10. Rule of Least Surprise: In interface design, always do the least surprising thing.

11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.

12. Rule of Repair: When you must fail, fail noisily and as soon as possible.

13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

16. Rule of Diversity: Distrust all claims for "one true way".

17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

    摘自< Art of Unix Programming>

基本Unix哲学

“Unix哲学”起源于Ken Thompson在早期关于如何设计一个小型但是有用而且服务接口清晰的操作系统的思考。随着人们对如何使得Thompson设计发挥最大效力的学习，Unix文化随之诞生并成长，并从各种途径汲取养份。
Unix哲学并不是一个形式化的设计方法。它从不在理论上宣称可以生产出更好的软件。也不能妄想指望它在一个很短的期限里使用糟糕的项目管理和廉价程序员做出一个极俱创新而又可以信赖的软件。
Unix哲学（以及其它领域内被认为是成功的“民间”传统）是自下而上的，而非相反。它注重实效并且基于经验。你不能在正式的方法和标准中找到它们，它们属于隐性、反身性知识。
Doug McIlroy， Unix管道的发明者也是Unix传统的奠基人之一，说
(i)让每一个程序只很好得做一件事情。当出现新工作的时候应该重组已有的程序而不是通过添加新特性使得原有程序变得复杂。
(ii)每个程序的输出应该可以成为另一个程序的输入，甚至一个未知程序。不让让彼此无关的消息混乱你的输出。尽量避免二进制输入格式。不要强求交互式输入方式。
(iii)设计和建造软件，包括操作系统，应尽早规划好。对于拙劣的部分不要犹豫不决，扔掉并重写它们。
(iv)使用工具可以减轻编程负担，即使你可能决定这些工具在建造后只使用几次。
他后来又这样总结：This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Rob Pike，一位伟大的C语言大师，从一个略微不同的角度给出了一些C编程的注解：
规则1： 你无法预料一个程序在何处花费时间。 瓶颈常会发生在出人意料的地方，所以在你能证明瓶颈所在之前，不要做第二次无谓的猜想。
规则2： 测量。在你测量之前不要盲目追求速度，除非某个部分的代码淹没了其它的。
规则3： 在n很小的时候，一个新异的算法会很慢，而且通常n不会很大。这些算法会有很大的常数。除非你确信n会很大，否则不要使用。  （即使n很大，也先适用规则2）
规则4： 新异的算法要比简单算法大得多，并且很难实现。 尽量使用简单得算法和简单得数据结构。
规则5： 数据支配。如果你准确选择了数据结构并正确组织它们，那么算法很可能已经自动构筑完成。 数据结构，而不是算法是编程的重点。
规则6： 没有其它规则。

Ken Thompson， Unix得设计和缔造者之一，用了禅宗里得一句话进一步描述了上面得规则4：
When in doubt,use brute force（告诉我谁把佛经翻译成了英语，我去杀了他）
更多得Unix哲学隐含在先哲们的行为以及Unix本身，而不是在先哲们留给我们的话语。纵观全局，我们可以总结出一部分思想：
1 模块化原则：编写简单的组件，用整齐的接口让它们互联。
2 清晰性原则：清晰要比灵巧重要。
3 整合化原则： 新设计的程序要考虑和其它程序共同工作。
4 分离性原则： 让机制与策略分离；让接口同引擎分离。
5 简单化原则： 为了简单而设计；只在你确信必要的地方增加复杂度。
6 吝啬性原则： 只有被证明了其它东西无法完成工作时才编写“大”程序。
7 透明化原则： 设计一个高度可见的程序可以使检查及调试更容易。
8 健壮性原则： 健壮性是透明化以及简单化的产物。
9 Rule of Representation:Fold knowledge into data so program logic can be stupid and robust.
10 最小立异化原则： 在接口设计方面，一定不要总想标新立异。
11 安静性原则： 当一个程序没有什么值得炫耀时，就不要炫耀。
12 修复原则： 是的，一旦当你不得不面对失败时，失败就会变得愈发喧闹。
13 经济性原则： 程序员的时间是宝贵的，把它让度于机器时间。
14 生产化原则： 避免手工hacking操作；尽可能让程序完成编程工作。
15 优化性原则： 先做模具再打磨润色；先让程序工作，然后优化它。
16 多样化原则： 千万不要信赖包治百病的药。
17 控制性原则： 多为将来考虑，因为它会比你预料更快地来到现实。

如果Unix对你还是陌生地，这些原则值得你去沉思。软件工程的教科书会也向你夸耀这里的多数原则；但是大多数操作系统缺少好的工具和传统，所以这些平台上的程序员根本无法应用它们。这些程序员不得不接受生硬的工具，坏的设计，疲劳工作以及过度膨胀的代码，甚至习以为常（他们甚至不知道Unix爱好者为什么如厌恶他们的工作和习惯）。

模块化原则：编写简单的组件，用整齐的接口让它们互联。
Brian Kernighan曾经总结说，“ 复杂度控制是计算机编程最重要的事情。 ”测试（debugging）决定了整个开发时间。好的方法可以事半功倍。
汇编器，编译器，流程图，结构化编程，“人工智能”，第四代语言（译者注：指各类*nix脚本语言），面向对象，以及不计其数的软件工程方法都试图并宣称解决这个问题，而然只要提升程序的复杂度，这些方法依然会因为人脑的限制而失败，在Fred Brooks看来，不存在“银弹”。
构筑一个复杂软件的唯一途径就是降整体的复杂性分担到一个个通过良好定义的接口互联的简单模块，多数问题是局域性的，这样完全可以修改出问题的模块而不破坏整体。

清晰性原则：清晰要比灵巧重要
软件的维护是重要的并且昂贵的，写出的程序并是仅仅给执行它的计算机处理，更重要的是要给你的人类朋友看，给那些将来维护软件的人看（这其中也包括你自己）。
Unix传统中，注释你的代码只是一部分。好的Unix方法同样会注重于你的算法和实现是否有利于将来的维护。为了一点点儿性能上的优势，而增加大量的复杂性是一桩糟糕的买卖。复杂的代码容易窝赃bug，更会让维护人员头疼。
优雅而简洁的代码，不易破裂且让修改者很容易维护。这点非常重要，特别是当这个维护者是几年后的你。
不要试图阅读那些复杂的代码超过三次。一次就读懂或许是侥幸，如果你发现很长一段时间后必须再次看它，而你已经忘记了细节。是时候为它编写注释了，这会让你第三次阅读时轻松很多。
-- Henry Spencer

整合化原则： 新设计的程序要考虑和其它程序共同工作
如果你编写的程序彼此间不能通讯，那么将无法避免过度的复杂性。Unix传统强烈期望程序可以读、写简单的、基于文本和流式以及设备无关的格式。经典的Unix中，有大量的程序作为过滤器（ filter）出现，过滤器从一个程序获得文本输入处理后再将文本输出。
出现这一情况并不是Unix程序员都不喜欢图形用户界面。而是因为如果不用字符流，程序间很难挂钩。
字符流作为消息传递的Unix工具是面向对象的。

一句话Unix哲学

所有这些这些哲学其实可以浓缩成一个被专家工程师奉为经典的法则：
KISS 法则
KISS 的全写是 KISS Is Simple,Stupid(或者 Keep It Simple, Stupid)
Unix能够给你提供一个极好的平台应用KISS法则。本书的余下部分会帮助你学习如何应用。

应用Unix哲学

这些哲学原则绝不是含糊的概念。在Unix世界，它们直接源于经验，并指导我们正在从事的具体开发实践。这里有一份可能尚不完全的表：

* 任何与源代码、目标无关的过滤器都要有一个。
* 数据流只要可能就应该是文本的（这样才可以用标准的工具阅读和过滤）
* 数据库规划和应用协议只要可能应该是文本的（文本可读、文本可编辑）
* 复杂的前端（用户界面）和负责的后端之间应该被清晰分离
* 如果可能，在决定用C语言编码前尝试解释性语言（译者注：包括脚本语言）
* 使用多种语言要比单一的语言好，除非这这会增加复杂性
* 更多得接受各种输入，对于输出则要吝啬的控制
* 过滤时不要丢掉你可能并不需要的信息
* 小就是好的，写程序时做到刚好能够完成你的任务

我们将会观察Unix设计规则以及从这些规则中导出的原则，并应用它们。就像预料中的，它们正成为其它领域内软件工程里最好的原则。

态度决定一切

当你面对正确的选择，去做它——在一个短期计划中，经常会是这样，而然在一个长期的计划中这也许并不能取得什么效果。如果你还不能确定到底改作什么，那么就做能让工作完成的最少的事情，至少在你确定真正正确的事情前。

正确地应用Unix哲学，需要你的忠诚。你必须绝对相信软件开发是一个要动用你所有智慧、创造力和激情的活计。此外你不能指望简单的套用过去方法实现现在的设计；你必须在你应该思考的地方进行新的编码。你会在不经意间使得本该简单的实现复杂化－接着你会疑问并抱怨为什么你的代码会迅速膨胀并难以调试。

正确地应用Unix哲学，充分利用你的所有时间不要浪费。如果某个人已经针对某个问题做出了好的解决方案，不要因为好面子而进行无意义的重复工作。不要做出比预计更复杂的设计，让设计轻巧更重要。用你的工具，让可能的事情自动化。

软件开发应该是一个令人愉乐的艺术，一个高级的游戏。如果你不同意这个看法，停下手边的工作，问问自己遗忘了什么？为什么你做软件开发而不是去挣更多的钱或者空耗时间？你必须将软件作为一件燃烧你激情的事情。

正确地应用Unix哲学，你需要接受这个态度。你需要维护它，需要去游戏，需要有探索的意愿。
我们希望你带着这个态度去阅读本书。或者至少希望本书能帮助你建立其这种态度。