Unix哲学,是指在Unix下开发小且有用软件的一系列文化规范和哲学观。 起源于Ken Thompson【注一】,后来又引入了其他顶级Unix操作系统开发者【注二】的经验。

Unix哲学强调建立短小、简单、清晰、模块化和可扩展的代码,可以很容易地维护,让后面的开发者能容易的重新利用。

Unix Philosophy

1. Doug McIlroy的三原则

Unix pipelines设计者,著名数学家、工程师以及软件设计师

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.

2. 罗勃·派克的格言和简化版本

罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的,但作为Unix哲学丝毫不为过:

Pike的第一、二条规则重申了高德纳的著名格言:“过早的优化是一切罪恶的根源。

Pike的第三、四条规则被肯·汤普森改述成:“疑惑不定之时最适合穷举。” 事实上,这两条规则也是KISS原则的具体表现。

规则五在之前Fred Brooks的人月神话中也被提及。Jon Bentley的《Programming Pearls》中也有一章阐述了相同的设计哲学。此规则作为“如果你的数据结构很好,那么控制它的算法就无关痛痒了”的例子常常被简化成“简约地写代码,聪明地用数据”。

第六条规则当然只是Pike针对蒙提·派森之小品Bruces sketch的幽默发挥而已了。

3. Mike Gancarz:Unix世界里至高无上的9条戒律

X Window系统设计组成员,Unix/Linux的倡导者,《Linux/Unix设计思想》作者

  1. Small is beautiful. 小即是美

  2. Make each program do one thing well. 每个程序只做好一件事

  3. Build a prototype as soon as possible. 尽早做出原型

  4. Choose portability over efficiency. 可移植性比效率重要

  5. Store data in flat text files. 在文本文件中保存数据

  6. Use software leverage to your advantage. 使使软件来充分发挥你的优势

  7. Use shell scripts to increase leverage and portability. 用脚本来增加效能和移植性

  8. Avoid captive user interfaces. 尽可能不用图形界面

  9. Make every program a filter. 让程序之间都可以串起来

4. Richard Gabriel的Worse is Better

理查德.加百列表明,Unix的一个关键优势是它体现的“worse is better”设计理念,他称之为“差点儿的更好”:系统的接口与实现都很简单,这比系统的其他任何属性都重要,包括准确性、一致性和完整性。加百列认为,这种设计风格具有重要的进化优势,尽管他也对一些结果的质量提出过质疑。

5. Eric Raymond的17条设计原则

著名黑客,《大教堂与市集》和《Unix编程艺术》的作者、《新黑客词典》(Jargon File)的维护人,他概况Unix哲学为KISS原则:"Keep it Simple, Stupid."以下是他提出的17条设计原则:

DesignRules.png

  1. 模块化规则(Modularity):开发者应该把程序打造成通过定义良好接口连接的简单部件,这样在将来可以通过替换部分程序来以支持新的功能;

  2. 清晰化规则(Clarity):开发人员应该让代码具有非常好的可读性,因为阅读和维护代码的的是程序员而不是电脑;
  3. 组件化规则(Composition):开发者应该让他们编写的程序易于与其他程序通讯;
  4. 分离规则(Separation):开发人员应该把策略从结构中分开,前端接口从后端引擎中分开。此规则的目的是使策略变更不影响架构的稳定性,从而减少错误的数量;
  5. 简单化规则(Simplicity):开发者应该寻找方式来简化系统设计,例如把大系统变成小系统,采取简单直接的操作等。此规则旨在给乐于设计“复杂而美丽”程序的开发人员泼冷水,因为这类程序极易发生问题;
  6. 简约性规则(Parsimony):开发者应避免编写大程序。此规则的目的是防止在失败或进度不理想的时候造成过度投资,因为程序员不愿扔掉花费大块时间开发的程序;
  7. 信息与决策透明的规则(Transparency):开发人员应该保证设计的可视化和可发现性,通过书面方式为以后的开发者留下留下思维过程;定义输入输出格式,使有效的输入和正确的输出更容易识别;此规则旨在减少调试时间和延长程序的寿命;
  8. 健壮性规则(Robustness):开发者要设计信息与决策透明、容易理解的的程序。因为复杂的程序中存在无法预见的情况,而容易理解的代码更容易进行压力测试。此规则的目的是帮助开发人员构建健壮、可靠的产品。
  9. 表达规则(Representation):当面临选择方案时,开发者应该选择使数据更加复杂,而不是程序逻辑更复杂,因为对人类来说理解复杂数据比理解复杂逻辑更容易。此规则的目的是使代码对于维护该程序的工程师更可读,从而可以进行维护。
  10. 最小惊喜规则(Least Surprise):开发者应在潜在用户的预期之上进行设计,例如,'+'在一个计算器程序中应该总是意味着增加。该规则旨在鼓励开发人员能够构建易于使用的直观的产品。
  11. 沉默规则(Silence):不打印不必要的输出;
  12. 维修规则(Repair):开发者应该把程序设计成容易是很容易定位和诊断失败,换句话说,设计的时候要在失败时叫一声。 该规则旨在避免一不留神一个程序的错误输出作为另外一个程序的输入。
  13. 经济规则(Economy):开发者应重视开发时间高于机器的时间,因为机器2013年比20世纪70年代便宜多了。这个规则旨在降低项目开发成本;
  14. 代码生成规则(Generation) :开发人员应避免手工编写代码,而应该是写一个抽象的高级程序生成代码。 这个规则旨在减少人为错误和节约时间。//抽象化规则;
  15. 优化规则(Optimization):开发者应该先开发软件原型,然后再优化。这个规则旨在避免开发者在边际收益上花太多时间。

  16. 多样化原则(Diversity):开发人者应该设计灵活和开放的方案。这个规则旨在提供程序的灵活性;
  17. 扩展性规则(Extensibility):开发人员应该为未来设计可扩展的协议,允许其他开发者在不修改程序架构下增添更多的插件。这个规则旨延长程序寿命,提高开发者代码的效用。

Reference

1. 注一

2. 注二


CategoryDesign

MainWiki: Unix_Philosophy (last edited 2013-04-19 19:01:51 by twotwo)