下面的内容大部分来自《unix编程艺术》这本书，少部分是我的一些理解。这是我读书的一个习惯，对于我认为重要的，我会把它打出来，在打字的过程中我会根据深入的思考理解。所以，笔记对我来说是一个思考和记忆的辅助手段。
1、模块原则：使用简单的接口拼接简单的部件
“计算机编程的本质就是控制复杂度”。
要编制复杂软件而又不至于一败涂地的唯一的方法就是降低其整体复杂度——用清晰的接口把若干个简单的模块组合成一个复杂的软件。如此一来，多数问题就只会局限于某个局部，那么还有希望对局部进行改进而不至于牵动全身。
注：控制复杂度，我在多个地方都看到过。把整体的结构搭建好后，各个模块也可以独立的演进而相互之间没有影响。
2、清晰原则：清晰胜于机巧
程序是给人看的，而不是机器。
这个原则不仅仅是指可读性，同时也指在选择算法和实现时就应该考虑到未来的可扩展性。不要为了提升一丁点的程序的性能就增加技术的复杂性和晦涩性——因为复杂的代码更容易滋生bug，也因为它会使日后的阅读和维护工作更加艰难。
优雅而清晰的代码不仅不容易崩溃——而且更利于后来的修改者立刻理解。
3、组合原则：设计时考虑拼接组合
如果程序间不能有效的通信，那么软件就难免会陷入复杂度的泥淖。
Unix传统极力提倡采用简单，文本化，面向流，设备无关的格式。
要想让程序具有组合性，就必须是程序彼此独立。在文本流这一端的程序应该尽可能不要考虑文本流另一端的程序。将一端的程序替换为一个截然不同的程序，而完全不惊扰另一端的程序应该很容易做到。
对于协议的设计，尽量采用简单的文本数据格式。
4、分离原则：策略同机制分离，接口同引擎分离
什么是机制：提供的功能；什么是策略：如何使用功能；这两个词有些费解。
策略的变化要远远大于机制的变化。将两者分离，可以使机制相对保持稳定，而同时支持策略的变化。
这条准则在GUI环境之外也被广泛应用。总而言之，这条准则告诉我们要将接口和引擎剥离开来。
“接口和引擎”？又是两个费解的概念。作者列举了两个实例，一个是Emacs，它是用LISP驱动C的程序来实现的——也就是使用内嵌脚本语言驱动c服务程序：c语言编写底层服务（引擎），给脚本语言调用，使用脚本语言实现流程。另一个实例是将应用程序分为协作的前端和后端，前端实现策略，后端实现机制。
可以认为接口就是策略（用户接口），引擎就是机制。
注：代码大全中提到“隔离变化”的概念，以及设计模式中提到的将易变化的部分和不易变化的部分分离也是这个思路。
#p#副标题#e#
5、简洁原则：设计要简洁，复杂度能低则低
来自多方面的压力使程序变得复杂，其中一种压力就是技术上的虚荣心。程序员都很聪明，常常以玩转复杂的东西和耍弄抽象概念的能力为傲。“看看谁能鼓捣出最错综复杂的美妙事物”：
“听起来自相矛盾，Unix程序员相互比的是谁能够做到“简洁而漂亮”，并以此为荣。
另一个眼里来自软件营销策略：看谁提供更多的功能——这会扼杀优秀的设计。
要鼓励一种文化，以简洁为美，对复杂的东西群起而攻之。
6、吝啬原则：除非确无它法，不要编写庞大的程序
大的含义：体积大，复杂度高；
避免编写庞大程序的方法的分割程序。一个程序只做好一件事情。
7、透明性原则：设计要可见，以便审查和调试
调试占看法的四分之三的时间，一个减少调试工作量的有效的方法就是在设计之初充分的考虑透明性和显见性。
软件系统的透明性是指你一眼就能看出软件在做什么以及怎么做的。显见性是指程序带有监视和显示内部状态的功能。这样的程序不仅能够运行良好，而且还可以看出它以何种方式运行。
设计时如果充分考虑这些，会对项目全过程带来好处。
8、健壮原则：健壮源于透明和简洁
软件的健壮性是指软件不仅在正常的情况下运行良好，而且在超出设计者设想的意外条件下也能够运行良好。
大多数软件缺乏健壮性，是因为过于复杂。
获得健壮性的方法：让程序的内部逻辑更易于理解。主要有两种方法：透明化和简洁化。程序越简洁，越透明，也就越健壮。
模块性（代码简朴，接口简洁）是组织程序以达到更简洁目的的一个方法。
