模块定义
1,空间小、结构完整，能独立调用的程序。
模块不能太大，否则无法灵活应用，程序的结构又必须独立且完整，以便于分解、组合，
供二次开发的程序自由调用。
有些模块需要与公用模块配合使用，由于公用模块为全部模块设计的基础，故仍可视为
独立调用。
2,效率高、弹性大，便于其它程序调用者。
二次开发的程序系建立在模块结构上，如果模块的效率不佳，必然会影响其操作。同时，
各种应用程序都有特殊的需求和条件，而模块则要考虑通用性，否则很难符合各种条件。
所以，在设计模块时，要考虑应用的弹性，使之既能适应各种需求，又能达成特殊的任
务。
3,功能明确，其变化以参数设定实现。
功能不明确，将会令应用者困惑，也就达不到预期的目的。功能明确与否，除了程序本
身外，手册及说明也占了极大的比重。
所谓功能明确，并非指明确的单一功能，而是指功能的分类。在分类时，需要有一种容
易分辨的方式，而最简单的，便是设置参数，凭参数作分支的条件。
将模块分类，为的是便于说明，以下的分类法，并非一成不变。原则上，模块可分
为：
1,功能模块：以所执行的功能加以分割者。
此类模块要考虑应用上的方便及功能的完整。然而，所谓功能的完整，只限于独立、单
一的目标，绝不可将多个不同的功能，设计在一个难以分割的模块中。
2,公共模块：没有明确的功能，但具有共享的效益，或其它某种特殊的目的，也可以
设计成为模块。
这种模块经常附属于其它模块中，设计时应注意其调用的灵活性，并应专设一目录，详
细记载其用途，以便随时查寻。
3,界面模块：介于两「面」之间，以解决两者问题之模块。一般在程序中，凡属数据
与数据间、程序与程序间、硬件与硬件间者，皆为界面关系，处理这种关系的模块即为
界面模块。
4,应用模块：应用者为人，工作者为程序，故提供给应用者操作的模块，概称应用模
块。
此种模块在实质上，仍属一种界面，但因为其实用价值关系到一个程序的成败，必须独
立考虑。
这种模块变化最大，随时有必要根据使用者的需求修改增减，故设计时要特别留意。
模块分割的基本原理
其实，除了知识在不断累积外，从古至今，人的智能并没有丝毫增长。
模块是一种极有价值的观念，任何事物的形体、结构、步骤，甚至于概念、认知等，
都可在以某个目标为前提之下，分析成为若干模块。有了模块，范围就会缩小、问题也
就变得单纯，比较容易掌握。如果能有效地利用模块，以之作为解决问题的手段，将是
无往而不利。
主旨精要
人生是有限的，为了有效的利用精力，以解决一切问题，应该学习掌握事物的原理。原
理之一，即为事物皆具有模块的结构，模块是事物组成之基础。有能力的人，一定善于
分析事理，了解事物的结构基础，得以从容不迫，在面对问题时，找到有问题的模块，
在其症结上下刀，问题便会迎刃而解。
模块分割
模块分割的原因不定，大约可分下列数种:
1,为了制作的方便，把程序分成模块，易于维护。
2,为了工作效率，或需要速度、或为节省空间的程序，分别用不同的技巧制作。
3,因程序员的工作能力，或工作条件而进行分割。
4,因程序的功能分类，分开制作，以便于灵活应用。
不论原因为何，分割模块前，一定要先确定目标，全面认知程序的格局，再加以整
理、归类，才能根据类别来分割。
分类确定后，再以分类来命名，以便于记忆及应用。这时格式的统一定义便是关键
所在。因为模块一多，相互间的调用极为频繁，如果格式不能统一，程序间常常需要因
应调整，反而增加了使用上的难度，得不偿失。
其次，各模块必须建立一个总表，而且要经常维护，务必与实际上所使用者一一对
应，切勿偷懒。每次调用时，还需修正记录，如使用次数，调用的程序等。
如果程序制作的规模大，参与人数多，最理想是由专人负责模块管理。从事这种工
作的人，必须头脑清楚，反应敏锐，而且要能任劳任怨，勤于更新。
模块特性
所谓模块特性，是指各个模块在设计或分割之初所考虑的因素。特性包括了功能，
效率的特别要求以及使用时应行注意的重点等有关模块的细节。
不论模块设计的目标为何，既然有了模块，就应该高度发挥其应有的效率。各个模
块之分割，皆有其必然因素，不论是为了功能，或是为了制作方便，目的都在追求效率。
而每个模块皆有其特性，要达到效率要求，应先了解模块的特性。
模块调用
模块的先决条件是要能灵活调用，否则就失去了其设计的意义。而且模块的目的之
一，是为了提供给其它程序员，作二次开发用。所以调用的方法，至关重要，必须面面
俱到。
程序流程
程序有一定的运行规律，称为「流程」，意即在执行时，依照预先安排的顺序，一
一流经的过程。
传统的程序写作法，流程非常重要，因为人需要根据一种理念，以逐步检验并付诸
实现。但自从模块受到重视后，每个模块代表一种完整的功能，而功能的集合所能实现
的效果，远非流程可以表达。这一来，流程的重要性减低了，其地位降到只属于结构中
的一部份而已。
因为模块是可组合的，模块越多，主流程便越短。虽然每一个模块也都各有其流程，
结构良好的模块，又可再细分为若干子模块，以此类推。因此，流程远不如模块灵活，
观念上也显得呆板。
不过，即使在模块设计过程中，有时也有必要借着流程逐步推理，以了解细部的结
构。在这种立场，流程的应用原无可厚非。可是一旦反客为主，程序员不用流程即无从
思考，就大谬不然了。
流程属于单线思考，人虽然经常使用这种流程推理，但更重要的能力却来自「抽象
思考」。抽象思考是指人在许多错综复杂、相互纠结的现象中，能立即掌握重点，针对
目的，解决问题。
在程序上，这种抽象思考相当于对所有模块的全面认知，而非仅仅是流程的推理。
有了全面的认知，灵活地加以调用，程序的功能就更上层楼，大大的提高了。
如果程序员只知道根据流程写程序，习惯养成后，不仅程序笨拙不堪，连人的思考
方式都连带受到影响。一般所谓的「匠气」、「呆滞」，就是这种机械式训练的结果。
因此，我不赞成利用流程来规划程序，但在解释或说明某种过程时，并不排除流程
的方便性。
工作进度
工作进度最重要的意义，不在于增加制作的速度，而是培养一种敬业的精神以及对
工作的判断能力。
工作进度的掌握靠进度表，而制作进度表需要对全部的工作有相当的认识。所以，
进度相当于全面地、有系统地思考工作的细节，对程序员的工作能力的提高有极大的帮
助。
当然，进度能有效地督促工作，每当进度如期完成，对程序员而言，即是一种成就
感。在制作大型程序时，时间往往拖得很久，如果没有进度作参考，人往往会有一种迷
失在汪洋，不知身在何处的失落感。
能力强的人，经常能正确判断工作所需的时间；反之，不知道工作需要多久，或者
所预定的进度与事实相差太远，都表示着程序员的能力有限或不足。
不过，写作程序完全要符合进度，也是不正确的观念。前文讨论过，写程序是种艺
术，而非流水作业式的生产，创造性强的艺术工作是不可能用进度来加以控制的。
进度的制作方式没有定则，只要记下工作项目，预计完成时间，实际完成时间即可。
只是制作是一回事，执行又是另一回事，唯有认真负责的执行，才会有实用的价值。
执行的方式不外每天或定期查阅进度，如果发现进度不符合，应该立刻分析原因，
并做修正调整。至于所分析的结果，最好能记载下来，以作下次改进的参考。
如此这般养成了习惯，自然而然，就有了自动分析判断的能力，而且还会增进规划
和设计的理念。