软件设计有两种模式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计得极为复杂，有缺陷也看不出来，第一种方式的难度要大得多。
模块化原则就是要编写复杂软件又不至于一败涂地的唯一方法，用定义清晰的接口把若干简单模块组合起来，多数问题只会出现在局部，还有希望对局部进行改进或优化，而不至于牵动全身。
相对于其他程序员，Unix程序骨子里的传统是：更加笃信重视模块化、更注重正交性和紧凑型等问题。
1. 封装和最佳模块大小
模块化代码的首要特质是封装，封装良好的模块不会过多向外纰漏自身细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用程序编程接口(API)----一组严密、定义良好的程序调用和数据结构来通信
有一种良好的方式来验证API是否设计良好：如果试着用纯人类语言描述设计（不允许摘录任何源代码），是否能把事情说清楚。
模块分解得越彻底，每一块越小，API定义也就越重要。全局复杂度和受bug影响的程序也会相应降低。软件系统应设计成由层次分明的嵌套模块组成，而且每个层面上的模块粒度应降至最低。
2、紧凑性
设计是否能装进人脑中，测试软件紧凑型一个很实用的好方法是：有经验的用户通常需要操作手册吗？如果不需要，那么这个设计(或者至少这个设计的涵盖正常用途的子集)就是紧凑的。
3、正交性
在纯粹的正交设计中，任何操作均无副作用；每一个动作（无论是API调用、宏调用还是语言运算）只改变一件事，不会影响其它。无论你控制的是什么系统，改变每个属性的方法有且只有一个。
4、STOP原则
任何一个知识的再系统内部都应当有一个唯一、明确、权威的表述。
重复会导致前后矛盾、产生隐微问题的代码，原因是当你修改重复点，往往只改一部分而非全部。
5.模块式编码
(1)有多少全局变量？全局变量很容易使模块轻率、混乱相互泄露信息
(2)模块内函数是不是太大了，如果不能用一句话来简单描述一个函数与其调用程序之间的约定，这个函数可能太大了
如果局部变量太多，倾向于拆分子程序。或者代码行是否存在太多缩进
