GreenGnn.ORG

《设计规则模块化的力量》

模块化就是为了减少循环依赖，减少耦合，提高设计的效率。为了做到这一点，我们需要有一个设计规则，所有的模块都在这个规则下进行设计。良好的设计规则，会把耦合密集的设计参数进行归类作为一个模块，并以此划分工作任务。而模块之间彼此通过一个固定的接口（所谓的可见参数）进行交互，除此之外的内部实现（所谓的隐参数）则由模块的开发团队进行自由发挥。

程序模块化的目的：

1. 减少循环依赖
2. 减少耦合
3. 提高设计效率

程序模块化的实施：

1. 把耦合密集的归为一个模块
2. 模块间通过固定的接口交互
3. 模块内部实现自由发挥

《宜家》

IKEA的研发体制也非常独特，能够把低成本与高效率结为一体。IKEA发明了“模块”式家具设计方法（宜家的家具都是拆分的组装货，产品分成不同模块，分块设计。不同的模块可根据成本在不同地区生产；同时，有些模块在不同家具间也可通用）。这样不仅设计的成本得以降低（因为基本每一种设计都是可制造的，不会因为大量的设计方案不具备可实施性而去莫明地浪费成本），而且产品的成本也能得到降低（模块化意味着可以大规模生产和大规模物流）。
IKEA的设计理念是“同样价格的产品谁的设计成本更低”，因而设计师在设计中竞争焦点常常集中在是否少用一个螺钉或能否更经济地利用一根铁棍上，这样不仅能有降低成本的好处，而且往往会产生杰出的创意。
可能IKEA是唯一能深刻理解“简单即美”的机构，他用“简单”来降低顾客让度成本，用“美”来提高顾客让度价值。

IKEA模块化目的：

1. 设计成本降低，都可实现
2. 产品成本降低，大规模物流和大规模生产

IKEA模块化实施：

1. 产品分成不同的模块，分块设计
2. 有的模块在不同的家具间可以通用

可以看出，两种模块化的实施都是类似的，耦合密集的区块分为一个模块，独立自由设计，提供开放接口。可以产生低成本，大规模生产和开发的效果。

互联网研发

互联网研发的流程，概念、需求产生，设计[产品设计，交互设计，UI设计]，开发[前端开发，后端开发]，测试，发布，然后第二版本 新的概念、需求产生，再执行一次研发流程。在这个环节中，概念的产生总是非常容易，研发的周期总是非常漫长，市场总是稍纵即逝。所以版本迭代的速度也就是提升的敏捷开发是一个企业竞争力的体现。

在前端开发环节中，如何运用模块化方法提升迭代的速度和开发效率呢？

首先，管理模块化，将流程进行模块化，分为策划，交互设计，视觉设计，前端开发，后台开发，测试，运维。每个流程都是高度耦合的，作为一个流程，流程之间采用公共接口进行衔接，也就是交付物。

其实是某一个流程中具体的模块化，就拿我熟悉的前端开发举例：

现在有某网站v 1.0版本发布，版本计划是这样的

• 产品策划 3人天
• 交互设计 3人天
• 视觉设计 3人天
• 前端开发2.5 人天
• 后端开发5人天
• 测试 2人天

共计 18.5 人天

为了在前端开发阶段提高效率，让两个前端负责开发，一人负责一部分页面，彼此没有沟通完全自由独立开发，1.5天后双方将代码合并，发现存在多处样式属性重叠冲突和js变量冲突，约定其中一个代码保持不变，另外一个代码进行调整，耗费1人天。

而如果两个人在开发前期使用0.5天进行沟通，约定好高度耦合的部分归为一个模块，双方按模块分工，模块内部自由开发，模块外部约定公共接口。然后1.5天后代码合并。提交后端开发工程师。

…

V1.0 版本发布

V2.0需求已经期待很久，又流程走到了前段开发阶段，需求是对局部功能进行改良优化，还是分两种情况

1. 非模块化代码设计，开发和解决代码冲突耗费2人天，其实开发只需要1人天
2. 模块化代码设计，开发耗费1人天

到了后端开发，进行后台开发，两种情况

1. 非模块化代码设计，页面html修改多处，模版文件进行多处修改
2. 模块化开发，仅仅这几个模块进行代码修改，修改模版工作量很少

从这两个例子可以看出，模块化在研发中版本的迭代速度是很快的，某公司产品以最快的市场应对速度赢得用户的认可和好感，获得可观的pv或者收入。

[未完待续..]