软件产品可以被看作是由一系列具有特定功能的组件组成，作为一个完整的系统也可以被分解成一系列功能模块，这些模块之间的相互作用就形成了系统的所有功能。

所谓模块是指可组成系统的、具有某种确定独立功能的半自律性的子系统，可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统。每个模块的研发和改进都独立于其他模块的研发和改进，每个模块所特有的信息处理过程都被包含在模块的内部，如同一个“黑箱”，但是有一个或数个通用的标准界面与系统或其他模块相互连接。

在软件的模块化开发过程中，把一个源代码的结构分割成一个元系统和一系列的模块。

元系统指的是一个能够保持系统运转的最小的系统。

模块是一个较大系统的独特的部件，它能够由设计者独立设计出来，同时又可以作为一个整体在系统中运转。

把一个大系统切割成互相独立的不同的小系统，可以使一些并不是经常见面的开发者减少必要的交流次数。

另外，一个旧版本的模块可以被新版的模块所替换，同时却又不影响整个系统的运转。

这样，在新模块中所增加的功能就可以及时在现存的系统中体现出来，同时也不需要更改系统中的其他模块。

高度模块化的源代码结构给软件开发者和使用者均带来了极大的好处。

开发者可以对具有某种特定功能的模块进行独立开发而不需要花时间去协调与其他模块之间的关系。

并且模块化开发不仅允许模块之间的水平开发，而且可以通过对类似模块之间的创新和竞争(开发新的模块或者对原有的模块进行改进)充分改善系统的功能。

另外，作为最终的用户来说，在安装系统的时候可以就个人的需求与偏好选择适合自己的模块。

模块化是复杂系统的一个共同特征，模块化的代码结构是由松散的组件构成的，是对一个系统完全意义上的分割，而不像完全集成的代码，各个组件之间存在很强的依赖关系，并不是完全通过界面来交换信息。

总结：

第一，把一个系统分解成各个不同的子模块，不同的开发者专注于对其中某一模块的开发，一方面实现了劳动的分工，另一方面也提高了自由软件开发的效率。基于模块化的性质，每个模块在开发出来以后都可以通过一个被称作是内核的原系统进行信息交流，发挥整个模块的功能，同时也并不会影响其他模块功能的发挥。而且在各个不同的模块整合在一起后，由于外部性的存在，会使整个系统增加的功能要超过该模块本身的功能。在此过程中实现了价值的分割与整合。

第二，对于开发者而言，基于模块化的自由软件开发具有更大的吸引力，其在参与开发过程中可以得到更高的期望收益。

第三，在非模块化的软件开发过程中，存在着严重的“搭便车”现象，当一个开发者选择参与开发，其余的开发者就会选择“搭便车”，最终会导致软件的供给不足；在基于模块化的开发过程中，所有的开发者都更倾向于参与开发不同的模块，从而实现整个系统的开发。

MIS软件开发中的组件模式开发比较复杂，主要的阻力不在代码的实现过程中，因为这个工作通常只应该占据软件开发工作量的30％，而对业务需求的深度剖析、业务子系统的划分和业务组件的规划会占据约40-50％的工作量。

这些工作体现在设计阶段主要是对业务的广度、深度分析，把业务领域的对象元素进行细化，将业务操作划分为原子性功能，以此为基础构成业务组件，进而形成模块和子系统，同时业务操作之间的约束则需要逻辑化（代码系统可识别的逻辑）；在此过程中，原系统也就形成了，它便是在业务领域中必须的组件、模块和子系统的集合；外延的组件在原系统上通过组合或热差拔即能够满足不同规模、深度、特性的业务模式运转。

万维钢

从前有两支队伍。A队伍的风格是整齐划一步调一致。他们的人员年龄差不多、学历差不多、想法差不多、连身高都差不多。他们做事的方法都经过反复的、严格的训练。他们处处服从指挥，做每件事都要依照上级的命令。

B队伍看上去有点自由散漫。他们的人员参差不齐，有老有少，有书呆子也有社会人，想法各异。他们做事花样百出，经常不按流程走，动不动就临场发挥。上级只给他们一个大致的方向，他们常常自己拿主意。

如果这是两支军队的话，A队伍肯定是正规军。B队伍有可能是个临时拼凑的游击队，但也可能是最精锐的特种部队。如果任务足够简单，A队伍肯定不折不扣地完成你的指令，B队伍则可能给你带来令人头疼的“惊喜”。

可是如果任务比较复杂、局面很不熟悉、对手非常陌生，我敢打赌，A队伍将遭遇惨败。B队伍是你唯一的希望。

如果这是一家公司，最适合 A队伍的角色大概是生产线工人、保安和服务员——研发和销售这种高端的活只能交给 B队伍。

可是领导们总是本能地、直觉地、甚至可能出于某种审美的需求，希望自己手下的系统像 A队伍。谁不喜欢一呼百应、令行禁止、如臂指使呢？但是这个世界的逻辑不是看你喜不喜欢。想要当好领导，有时候就得克制本能的权力欲。

美国环境科学家唐内拉‧梅多斯（Donella H. Meadows）在《系统思维入门》（Thinking in Systems: A Primer）这本书中总结，好的系统应该有三个特点：第一，它要有抗打击能力；第二，它要有自组织能力；第三，它应该有一个健康的层级结构。

这三个特点，全都违反领导直觉。

1.抗打击

以前我们专栏提到过“抗打击能力”（resilience）这个概念。我们直觉上好东西就应该好好保护起来，避免遭受任何打击——其实连养孩子都不应该这么养。最理想的系统得能抗打击，反脆弱，不怕事儿。

人体就是个好系统。免疫系统能挡住绝大多数病毒。温度高点儿低点儿，工作苦点儿累点儿，情绪好点儿坏点儿，我们绝大多数情况下都能承受。人，其实非常不怕折腾。森林和草原的生态系统也都具备相当的抗打击能力，哪怕是历经一把大火，过几年又是生机勃勃。

这些系统都是活的。活的东西，才有可能越挨打击越顽强，才有可能随机应变。怎样才能让系统抗打击呢？

首先“抗打击”不等于“不变”，也不等于就是追求“稳定”。一成不变的系统反而是脆弱的。我们知道保持系统平衡的是负反馈回路。负反馈回路的作用不是让系统不出状况，而是出了状况能给扭转回去。一个具备抗打击能力的系统得能经得起扰动，取得一个动态的平衡。

其次，系统要具备一定的冗余度，它需要有一个比较宽松的环境。

我们前几天讲过，生活中有很多“优化者”，追求极端的效率，可丁可卯地安排系统的运行，这样往往就会让系统丧失抗打击能力。比如像戴尔和丰田公司，据说讲究一个“零库存”，说几点钟用哪个零件供应商就必须在几点钟正好把零件送到工厂门口。这么做效率固然是最高的，但是也容易出差错—万一出状况，系统就容易陷入问题。

再者，最理想的系统的反馈回路本身，也要有自己的反馈回路。比如说，一个社会系统光有警察还不行，警察本身得能不断适应新局面才行。

这就要求系统得能学习、能自我修复、能动态变化。这就引出了好系统的第二个能力。

2.自组织

好系统必须是能创新的系统，它不可能按照一张宏伟的蓝图按部就班地发展。未来的情况可能跟今天非常不一样，真正的好系统不但能适应变化，而且还得能制造惊喜。

惊喜不是总设计师规划出来的，得指望是系统内的每个成员自己创新。

现在有不少大公司就很支持员工在企业内部创新，甚至可以说是创业。几个员工自发地做一个项目，如果做得好，企业就可以资助这些员工，让他们干脆就成立一个小组把项目做大做强，这就是一种“自组织”。

自然界有很多自组织现象，像雪花、湍流、沙丘，特别是生命，都是自组织的例子。自组织，代表没有事先计划的、起源于局部的、自发的创造。有人群协作就有可能产生自组织，市场经济的本质就是允许民间自组织。

但是容忍自组织，可不太容易。自组织会让系统显得不一致、不统一、不规范，自组织主导的局面可能是不可预测的。你不知道它会在什么地方、因为什么原因而出现。想要出现自组织，系统必须向基层放权，给一定的自由，还得允许实验。自组织让系统表现出一定程度的无序和混乱，你能容忍这样的混乱吗？

现在“创新”绝对是个好词儿，每个人都说要鼓励孩子创新——但不管是中国还是美国，中小学老师们，其实并不真的喜欢爱创新的孩子。老师让他这么干他非得那么干，老师指东他往西，这才是创新。可是谁不希望令行禁止、谁不喜欢指挥整齐划一的队伍、就好像朝鲜拉拉队那样？对老师来说，有创新精神的学生是个麻烦——你按规定的动作练好就行了，不要胡乱给自己加戏。

所以我看大多数领导说创新其实都是叶公好龙。你对自组织有多大的容忍度，才谈得上能有多大的创新。

古今中外的政府都限制自组织。国家的经济政策常常是向已经成型的大企业倾斜，小企业想要发展壮大分一杯羹是有门槛障碍的。

前几年有本书叫《国家为什么会失败》（Why Nations Fail，作者是德隆·阿西莫格鲁和詹姆斯·A.罗宾逊），说为什么前苏联的经济越到后面越缺乏活力呢？其实苏联的工厂一开始建的时候还是比较先进的，问题在于它不允许新工厂跟它竞争。你想用新技术办个新企业，根本不可能，因为老工厂有政策保护。如果国家政策只会力保老工厂，又何谈创新和活力呢？

这就引出了下一个问题：好系统的上下级，到底应该是什么样的关系。

3.层级关系

小公司也许可以做到绝对的权力平等，大公司必须得有层级关系。

层级，就是把一个大系统分成若干个子系统，每个子系统可能又有各自的子系统。层级就是模块化。

梅多斯在《系统思维入门》里举了一个例子，生产手表。一块好手表里可能有上千个零件，一个一个安装的话，一旦有问题就非常麻烦。解决办法是把零件给模块化——若干个零件组成一个模块，一个模块一个模块地生产和组装，最后再把不同模块组装在一起，就成了手表。

我看到有报道说，中国现在制造航天火箭就已经实现了模块化，而这样能大大提高工作效率和安全性。

有这样的好处，关键在于信息——每个零件只要跟自己模块里的零部件配合就行。比如一个公司分成若干个部门，每个部门就是一个子系统。部门内部的信息交流显然更强，每个人大多数情况下只和自己部门的人打交道就可以了，并不需要时刻对全公司负责，这就避免了信息过载。

各个子系统在相当程度上是自治，这就不会有点什么事都搅动整个系统。人体就是个分了很多层子系统的大系统。人体中有各个器官，器官中又有组织，组织又是由细胞组成的。我们之前说“头痛医头脚痛医脚”是个贬义词，但实际上医生治病，大部分情况都是头痛医头脚痛医脚。如果一个人的胳膊受伤，医生把胳膊处理一下就可以了，通常不用考虑他的心理问题，也不用考虑他的肾是否能承受得了。有了子系统就有这个好处。子系统出问题，不用非得牵动全身。

任何系统要变大、变复杂，就一定要有稳定的各种子系统结构。

子系统的良好运行，应该在整个系统中有很高的优先级。作为个人，你不能为了实现自己的价值不顾所在集体——也就是你所属的那个子系统——的成败。作为大系统的中央，也不应该对子系统有太多的直接控制。

一个好系统，中央控制和子系统自治必有一个平衡。

|由此得到

好系统首先要不怕打击；为了不怕打击，系统就要自己更新自己学习，这就要求自组织能力；为了更好地实现自组织，协调好自组织和大系统的关系，就要有健康的层级结构。有了稳定的层级结构之后，系统的抗打击能力又会进一步增强。

这样的系统充满活力，能适应各种新局面。它会变得越来越复杂，越来越强大。

咱们今天说的似乎都是企业和国家这样的大系统，但是这三条对个人的学习和发展系统也很重要——

想要有抗打击能力，你就不能依赖单一的技能，不能指望一成不变的稳定工作，要建设好自己的负反馈回路。

想要发展创新，你就得有自组织能力，你要不断探索新事物，尝试新做法。

想要做大做强，你就不能事无巨细全靠自己，你要善于利用现有的工具，善于跟别人模块化地对接和合作。

死气沉沉、整齐划一、令行禁止，那不叫好系统。活力、自由、赋能，这才叫好系统。

有关系统思维我们暂时就讲到这里。系统论说起来并不难，真正用好可不容易，我们讲的这些可以说都是纸上谈兵。但是只要你脑子里有了这根弦，以后看问题，必然就多了一个角度！

万

高内聚性、低耦合性、可重用性等。

1、高内聚性：模块内部的元素紧密相关，模块内的功能和任务应该高度相关，并且模块内的各个组成部分协同工作，以实现特定的功能。高内聚性意味着模块的功能单一，且模块内的代码尽可能减少对外部其他模块的依赖。

2、低耦合性：不同模块之间尽量减少相互依赖和关联。模块之间的接口简洁明了，以降低模块之间的相互影响。低耦合性能够提高代码的可维护性，可测试性和扩展性，使得系统更加灵活和易于修改。

3、可重用性：模块化的设计追求将系统划分为可以独立使用和重复利用的模块。模块可以在不同的项目中被重复使用，减少了开发时间和工作量。通过提高模块的可重用性，可以降低系统开发成本，并提高软件的质量和稳定性。

转载请注明：片头模版 » 模块化的三个重要特征(模块化的三大特征)