软件设计的高内聚、低耦合

随着PMTalk版本的不断迭代，到现在我们已经迭代到5.0了，上线了3年班，在这漫长的时间里，一个产品会在研发中、产品设计有什么问题呢？

这里的问题主要是包含三类

1.技术人员不断变换，代码规范层次不齐

无论是在大厂还是在小团队，项目早期以快、业务实现为要求，比如高并发、数据仓库、风控控制都不会接入。

而互联网团队的开发人员、产品经理一般在职时间1-2年会正常生命周期，在系统还没有变现下、或探索期人员经历大量的变动。

所以代码的可维护性就越来越差，比如在PMalk我们早期采用的JS、后续才使用react框架。

在项目早期团队为了快，使用开源系统做二次开发，但却为后面的迭代、优化埋下了定时炸弹。

以至于现在的前端开发同学找到我，经常会说需求可以先放下，我们优先做重构吧，现在的代码看着太费时间了，先别说改。

2.业务发展的不明确，产品结构的混论

在早期PMTalk还只是一个提问发布的论坛，我们也没有想到最终会做成一个视频、兼职工作、体验报告于一体的互联网社区。

但其实中间我们至少花了半年的时间做新功能探索、业务的定型、以及数据验证。

关注我的朋友应该知道，我一直敲强调产品是业务的承载形态，而业务没有定型自然就会导致产品框架乱改。

比如曾经我们定位自己不做活动报名系统，只做第三方活动跳转。在产品框架上就只允许运营、用户通过平台跳转到第三方进行报名。

后续因为活动人数与用户可控性等方面原因，自己做活动报名系统就要求做用户管理、活动管理的升级。

3.业务逐渐定型，产品规划逐渐倾向于T型发展

一个互联网产品在3年以后，其实算得上“高龄”了。因此此时产品框架已经形成了用户主要使用的路径，在此时的版本重构上会要求严格保留前期核心功能，针对边缘化优

在用户体验要素里，就提到最底层、抽象的战略层其实就是T型发展的依据。针对确定的业务不大改

产品上线时间越久，越要高内聚、低耦合

回答开篇提到的问题：

“如果一个产品上线了3年，需要解决什么问题？”

其方向就是不断的内聚核型功能做成通功能，将个性化的业务进行边缘化拆解，做成非通用的能力。

同时一个产品正常运营3年，首先他的业务也在不断发展、内部员工也在增长，在高增长的背后自然就会出现开头前面2类的问题。

互联网产品也属于软件工程，在其高内聚、低耦合是我们开发过程中要求紧密遵守的。

每个模块相互联系越紧密，则耦合性越高，模块的独立性就越差，反之同理；

再举个案例：

一个项目中有20个方法调用良好，但是要修改了其中一个，另外的19个都要进行修改，这就是高耦合。如果修改了其中一个，只需要再改2个，则属于低耦合。

从这个案例可以看出，保持这样的软件方法可以大大减少时间成本。

3年时间，产品不断迭代，也会从一个小应用演变到高级阶段就是一个大工程，从头到尾由一个人实现是不可能的，于是就要分工模块化完成。

比如PMTalk早期通过后端服务端渲染，现在变成了前后端分离就是逐步演变分工。

即使是由一人完成的程序，内部按照MVC模式的话，也会由subroutine来完成各项功能。于是，对于模块化的开发，就有了这样的要求：高内聚低耦合。

MVC 模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

软件设计的耦合的8种状态

在这里我收集到了常用的耦合关系，包含数据、功能、业务等3个维度。可以以此判断是否为耦合

1.无直接耦合

指的是两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。

2.数据耦合:

指两个模块之间有函数调用关系，传递简单的数据值，相当于高级语言的值传递;

3 标记耦合:

指两个模块之间传递是数据结构，如数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;

4.控制耦合:

指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该变量的值有选择地执行块内一功能;

5，外部耦合：

一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合，外部耦合和公共耦合很像，区别就是一个是简单变量，一个是复杂数据结构。

6.公共耦合:

指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。

7 内容耦合:

这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。

或许在年夜前还能在保持原创做内容，实际上已经不是一种任务了。而是变成一了一种定时输出。

趁着春节假期，我们团队也在发布弱小版本，尤其是移动端的小程序预计在春节也会上线。