摘要：
《怎样将系统模块化》一文阐述了系统模块化的重要性，应遵守的高内聚低耦合的原则。以及经常使用大粒度的划分方法,并对一些原则进行了对应的补充说明。当然要编写出高质量的软件程序。还须要理清需求，把控好设计，使用恰当的技术，处理好业务逻辑。编写高质量的代码，更须要一遍又一遍的重构改进
废话：非常久没有写代码了。也非常久没有从事软件开发设计的工作。想想之前设计编写代码日以夜继的日子，还是蛮怀念的~近期在带领人员做一些项目的时候，发现开发出来的软件可改进的空间还是蛮大的，如系统模块划分不清。代码编写质量不高等，当然要编写出一个好的程序不是一件easy的事。须要理清需求，把控好设计。使用恰当的技术，处理好业务逻辑，编写高质量的代码。更须要一遍又一遍的重构改进.
当然追求完美，本身就不完美，绝大部分的情况下，也没有充足的时间同意这样做。只是追求完美的心态还是值得肯定的，不然也没有动力改善自身的技能水平，若能有经验的长者加以引导，少走一些弯路。那对人员的成长大有裨益。当然修行还是靠自身。
提升自我，正视自我的不足，也会使得人员备感压力，值得欣慰的事。人员还是挺上进努力的。仅仅是任重道远，简言之，革命尚未成功。同志还需努力！
扯远了。回正题，这里先将软件需求以及代码编写质量的内容暂且置于一旁，这些也非三言两语所能说完，况且自身的修为也不够。这里还是集中精力重点说下系统模块化的划分，顺便也借此温故而知新：
系统模块化的重要性：
对于绝大部分的项目而言，系统模块化的重要性不言而喻。一个良好的模块划分能够使得系统。具有下面优点：
1． 更高的可靠性，将系统划分成一个个相对独立的模块，有利于开发者缩小问题域，集中精力解决单一模块存在的各种问题异常，通过局部改进，终于使得软件的可靠性得以改善.
2． 更稳定的结构，遵循高内聚低耦合，将不同领域的模块分隔开来，并保留简单高效严谨的通信接口，可以有效的避免一个功能模块的问题扩散到还有一模块
3． 更强的维护性，良好的结构划分。清晰的代码逻辑，具有更好的可读性。便于开发者理解维护
4． 代码可重用性更强，系统模块化可以使开发者更好的理清业务逻辑结构，提取出公共的模块。从而提高代码的可重用性
5． 缩短项目开发周期。採取分而治之的策略，分块解决这个问题。使得问题更易于处理。且更加可控，降低问题处理重复所投入的不必要时间
系统模块化的原则
依据软件设计的模块化。抽象。信息隐藏和局部分等原则，能够得出模块化的独立性概念。所谓模块独立性，即模块内部逻辑相对独立完整单一。模块间联系尽可能少，详细表现为高内聚低耦合。
符合高内聚低耦合的模块，通常功能完整独立，数据接口简单，程序易于实现。易于理解维护，同一时候也限制了错误的作用范围。使错误易于排除，因而可使软件开发速度快，质量高。
内聚度
内聚度是指模块内部的联系紧密程度，联系越紧，则内聚度越高，模块独立性越强，系统越易于理解维护。具有良好内聚度的模块应能较好的满足于信息局部化的原则。功能完整单一。同一时候。模块的高内聚必定导致模块的低耦合度。
理想的情况是：一个模块仅仅使用局部数据变量。完毕一个功能。
按由弱到强的顺序。模块的内聚度可分为下面几类：
1． 偶然内聚：块内的各个任务没有什么有意义的联系，仅于偶然位于同块，若非时空限制，不应使用
2． 逻辑内聚：一个模块完毕的任务在逻辑上属于同样或相似的一类(如依据參数不同。模块输出多种结果)，但这样的内聚的模块存在一些致命的问题。如修改困难，模块内部修改，须要考虑到其他模块的调用影响；模块内部须要判别调用者，使得模块外部间的联系添加。内部推断陷阱的产生以及装载整块所带来的性能下降等等
3． 时间内聚：是指一个模块中包括的任务须要在同一时间内运行（如初始化，结束等所需的操作）
4． 过程内聚：一个模块内的各个处理元素是相关的。并且必须按固定的次序运行，表现为有次序的流程，面向过程化的思维很多其它的是採用这样的方式进行模块/函数的划分
5． 通信内聚：一个模块中的各处理元素 须要引用共同的数据
6． 顺序内聚：一相模块内各处理元素关系密切，必须按规定的处理次序顺序运行，后运行的语句/段往往依赖先运行的语句/段
7． 功能内聚：模块仅完毕一个单一的功能。且该模块的全部部分是实现这一功能所必须的，没有多余的语句。功能内聚是内聚度最高的一种模块类型，结构紧凑。逻辑清晰。易于理解。便于维护，可靠性强，稳定性高，因功能单一，复用性高。在划分模块的时候，应追求此类型。
耦合度
耦合度是从模块外部考察模块的独立性程度，用来衡量多个模块间的相互联系。普通情况下耦合度应从下面三方面考虑：
耦合内容的数量：模块间发生联系的数据和代码的多少，多则高，少则低；
模块的调用方式：模块间代码数据共享的方式，直接调用。依赖调用，载入调用等
模块间的耦合类型：耦合类型有下面几种方式：
独立耦合，模块间彼此独立，没有直接联系，且属于同个软件系统或隶属同一上层模块
数据耦合，模块间彼此交互数据，接受返回值。传递数据參数，通常应保持模块间的关系为数据耦合
控制耦合。模块间传递的是控制參数而非数据參数，用于控制还有一模块的处理逻辑，这说明还有一模块内部存在多个并列的逻辑路径，通过提高被调用模块的内聚性，能够彻底的去除这样的联系。因为添加了设计理解的复杂度。应避免使用该耦合方式。
公共耦合，又称公共环境耦合或数据区域耦合。若模块间对同一数据区域进行存取操作，则模块间的关系为公共耦合。
内容耦合，一个模块直接訪问还有一模块内部代码或数据，出现内容耦合。
内容耦合严重破坏了模块的独立性和系统结构化，代码互相纠缠，执行错综复杂。应全然不使用内容耦合
系统模块化方法
下面列举常见的大粒度模块划分方法
基于需求功能划分：依据用户需求归类的不同，对模块进行大粒度的划分，如用户管理模块，订单流程模块等
基于系统层次划分：依据模块上下级，同层类别的关系进行模块划分，如展现层，业务层，数据层等
基于专业领域划分：依据解决的问题域的不同。对模块进行划分，如人机交互领域。数据库领域，网络通信领域，数据加解密。图形图像等