模块性：保持清晰，保持简洁 1（unix编程艺术摘录）

             软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷，另一种设计得极为复杂，有缺陷也看不出来。第一种方式的难度要大的多。

 代码划分的方法有一个自然地层次体系，随着程序员必须面对的复杂度日益增加，这个体系也在演变中，一开始，一切都是一大块机器码。最早的过程语言首先引入了用子程序划分代码的概念。后来，我们发明了服务程序库，在多个程序间共享公用函数，再后来，我们发明了独立地址空间和可以相互通信的进程。今天，我们习以为常地把程序系统分布在通过成千上万英里的网络电缆连接的多台主机上。

  Unix的早期开发者也是软件模块化的先锋。在他们之前，模块化原则只是计算机科学的理论，还不是工程实践，在研究工程设计中模块经济性《设计原理》这本探路性质的著作中，作者以计算机行业的发展为研究案例，并认为， 相对硬件而言，Unix社区实际上是第一个将模块分解法系统地应用到了生产软件中，毫无疑问，自从19世纪晚期人们采用标准螺纹以来，硬件的模块性就一直是工程技术的基石之一。

  模块化原则在这里展开来说就是：“要编写复杂软件又不至于一败涂地的唯一方法，就是用定义清晰地接口把若干简单模块组合起来，如此一来，多数问题只会出现在局部那么还有希望对局部进行改进或优化，而不至于牵动全身。

  相对其他程序员而言，Unix程序员骨子里的传统是：更加笃信模块化，更注重正交性和紧凑性等问题。

  早期的Unix程序员擅长模块化是因为他们被迫如此，操作系统就是一堆最复杂的代码，如果没有良好的架构，操作系统就会崩溃，在人们早期开发Unix时候就犯过几次这种错，代码不得不全数报废。虽然大家可以把这些怪罪于早期C语言，但主要还是因为操作系统太复杂，太难编写。所以，我们既需要改进工具，也需要养成使用工具的好习惯，这样才能应对这种复杂性。

                                                                                                                        ————ken Thompson

  目前Unix黑客为此在很多方面进行了艰苦的努力，1970年的时候，函数调用开销昂贵，不是因为调用语句太复杂，就是因为编译器牺牲了调用时间来优化其他因素，如快速内层循环。这样，代码往往就写成一大块，Ken和其他早期Unix开发者指导模块化是个好东西，但是他们记得PL/1的经验，不愿意便便编写小函数，怕影响性能

   Dennis Ritchie告诉所有人C中的函数调用开销真的很小很小，极力倡导模块胡，于是人人都开始编写小程序，搞模块化，然而几年后，我们发现在PDP_11中函数调用开销仍然很昂贵，而VAX代码往往在“CALLS”指令上话费掉50%的运行时间，Dennis对我们撒了谎！但为时已晚，我们已经欲罢不能...

  今天所有的编程者，无论是不是Unix下的程序员，都被教导要在程序的子程序层上进行模块化。有些人学会了在模块或抽象数据类型层上完这一手，并称之为“良好的设计”。设计模式运动 正在进行一项宏伟的努力，希望更进一步，找到成功的设计抽象原则，以组织大规模程序的结构。

  将这些问题做一个更好的划分是一个有价值的目标，而且到处都可以找到有关模块划分的优秀方法。我们不期望太深入地涵盖与程序模块化相关的所有问题：首先，因为该论题本身就足够写整整一本书，其次，因为这是一本关于Unix编程艺术的书。