g随着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 内容耦合:
这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。
或许在年夜前还能在保持原创做内容，实际上已经不是一种任务了。而是变成一了一种定时输出。
趁着春节假期，我们团队也在发布弱小版本，尤其是移动端的小程序预计在春节也会上线。
关注我的个人微信：574319420，多交流
