从电子管到今天的多核处理器，从数米长的打孔纸带到如今的百万行程序源码，在每年都在不断涌现的新概念新名词的喧闹中，模块化一直以它不变的静寂默默的存在。它就像是变形核心（
Transformation core
），让软件可以在各种复杂的构造间变换。但是，现实情况往往相反，因为人会犯错误，而犯错误是正常情况，人们在尝试、犯错、纠正中进步。
做软件的起点往往是简单应用开发，这种情况下一般是不需要考虑结构问题的，因为常用模块框架都已经设计好了，只需要像搭积木一样把应用搭起来。但是一旦所要开发的应用超出模块框架预先设计的范围，就变得很困难了。一个好的框架会培养使用者对结构的理解，而使用者可以模仿现有框架的思路去解决新的问题。不过，简单应用开发的工作大多强调一个快字，根本没有时间去深入体会，很快就变成了代码的堆积。
另一种则是从一堆的设计思想、设计模式开始，而又缺乏足够的经验来真正理解这些内容，往往导致过渡设计（
Over-engineer
），使结构异常复杂，难于维护。人们引入各种设计方法，目的是为了解决和简化问题，如果反而弄复杂了，不妨回头想一想哪里弄错了。
一个程序不会一蹴而就，一般要经过反复的修改，设计好的情况下，也就是模块的重新组合。如何做出好的模块化设计，经典的“高聚合低耦合”六字箴言大家应该都很熟悉了，这里说一些自己的体会。
原则一：复杂性局部化。
不管计算机能发展得多强，人脑在同一时间能理解和思考的范围是有限的，所以一个好的结构要能有效地控制程序的复杂度，使每个模块内要考虑的问题范围尽量小。所谓局部化，就是使其只需要在这个局部模块考虑这个问题，在局部解决问题，其他模块只需要调用这个局部模块而不再需要关心细节。局部化的另一个好处是便于优化。因为集中到一个局部模块，即使牺牲可读性来提高性能甚至使用
hack
的方法，所造成的印象都只限于局部，而不会增加整体的维护难度。
原则二：准备被重构（
Designed to be refactored.
）
书籍里教授编程好习惯总是要提到可扩展性，要大家做复杂的设计以应对未来的扩展。不过，实践经验往往是，费力设计好扩展性的代码从此再也没有动过，反而是没准备的地方需要大改特改。为什么？因为我们不能准确预测未来，能的话改行去炒股好了。所以过早地考虑扩展性往往没用，即使真有一天需要扩展，也会发现新的需求是之前根本想不到的。一份代码，如果要长期开发下去，早晚得重构；不长期开发的话，费力去设计超出当前需求的结构又纯粹是浪费时间。所以说，准备被重构，代码结构设计成便于日后重构的，在满足当前需求的前提下，一切从简。