Unix设计哲学

初次接触unix设计哲学的概念，简单学习下，或许有助于业务系统的架构设计。以下为网络转载：

1、模块原则：写简单的程序，并用好的接口连接它们 编程的核心是控制复杂度。Brian Kernighan

开发一个项目的绝大部分时间都用来Debug了unix系统设计，所以完成一个项目更多是因为能够控制好Debug的时间和复杂程度。只有一种办法可以有效的控制复杂度：作出简单的子系统，然后用精心设计的接口把他们连接成一个应用。

2、清晰原则：清楚透明的算法比“高明”的算法更好

维护系统的成本非常高，在写程序的时候就应该首先注意程序的可读性，而不是效率。因为，归根结底这些程序是留给其他程序员或者开发者本身阅读的。

实践这个原则包括：良好的注释，简单明了的算法。注释的功能容易理解，简单明了的算法则是因为通常简单的算法更加容易维护且不容易出问题。所以，在性能允许的情况下，尽量选择简单易懂的算法。

永远不要超过三次靠努力思考才能看懂一段代码。第一次可能是侥幸看懂了，但是如果你发现过了一段时间你又需要重新思考一遍才能看懂这段代码，因为你忘了上一次是怎么想的了，这时候你应该注释掉这段代码，这样你就不会第三次为了这段代码发愁了。 3、组装原则，Composition：写能够跟其他程序一起工作的程序

如果你写的代码不能够互相交流，不能相互组合，那么你的代码很快就会成长成一个难以维护的巨大怪物。因此Unix的编程传统鼓励写输入、输出基于文本的程序，很多Unix程序其实就是一个简单的Filter，输入一串字符，输入另一串字符。

从实践的角度，在我们写程序的时候尽量使用简单的字符作为接口，而不是复杂的二进制文件，甚至GUI。

4、隔离原则，Separation：分离接口（使用引擎的方法）和引擎

前后端的分离是一个很好的例子。

5、简单原则，Simplicity：尽量简化算法，不到必要的时候不要增加复杂度

Unix的工程实践形成了这样一种文化：更加欢迎简单的解法，更加注重把系统分解成小的部分。

6、简约原则，Parsimony：只要在必要的时候才写大型程序，通常小程序已经足够

如果程序变得越来越大，就会渐渐失去可维护性。

7、透明原则，Transparency：写容易测试和纠错的代码

写出“透明”的程序至少需要如下两个特性：程序非常直观容易理解；程序有清晰的内部状态并且可以打印，比如日志。

写出“透明”的应用需要在上面的基础上，增加一个特性：使用简单的接口。

8、健壮原则，Robustness：这是简单和简约的副产物 9、表达原则，Representation：用数据结构表达逻辑，而不是用过程表达逻辑

即使是简单的描述过程的语句，对于人来说仍然需要花费很多精力去理解。相反的，即使是复杂的数据结构，人也可以快速的理解。在编程的背景下，数据结构比指令更容易被人理解，也就更容易维护。因此，在编写程序的过程中，应该尽可能的把过程逻辑写入数据结构中。

10、传统原则，Least Surprise：用最常识的方法设计借口

尽量按照业内习惯书写程序，写成程序的时候，就像写书一样，应该时刻想着以后阅读你程序的人（有可能就是未来的你自己），尽可能让他们更加容易的理解你写的程序。

11、安静原则，Silence：如果程序没什么特别事情要表达，应该保持安静！

参考透明原则，不能过度的输出信息，扰乱用户！！

12、经济原则，Economy：程序员的时间比机器的时间更加宝贵

选用一个表达更强、但是慢的语言，很好！节约程序员的时间，浪费机器的时间很划算！而且，更好的编译器可以迅速的提高运行速度。

13、生成原则，Generation：尽量写代码来生成代码，而不是手工输入代码

人，太容易写错了。。。。

14、修复原则，Repair：当程序出现异常，应该明确的抛出异常，而且约早越好！ 15、优化原则，Optimization：先让程序工作，在考虑优化的事情

不要过早的开始优化程序，应该快速实现原型

16、多样性原则，Diversity：一个问题有很多好的解决方案，没有最好的解决方案！

不要纠结最好的方案，因为没有！！

17、拓展性原则，Extensible： 设计程序时应该考虑到未来的拓展，因为未来比你想象来的早

特别是设计接口的时候。

应用

如何应用这些原则呢：

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!