随着PMTalk版本的迭代，到现在为止我们一直迭代到5.0，上线了三年的班级。 在这么长的时间里，有一个产品正在研发中，产品的设计有什么问题呢？
这里的问题主要包括三类
1 .技术人员不断变化，代码规范水平参差不齐
无论是大工厂还是小团队，在项目初期都要求快速实现业务，包括高并发性、数据仓库、风力发电控制等。
而互联网团队的开发者、产品经理一般在职1-2年才能迎来正常的生命周期，系统尚未变更，或者探索期间人员大幅变更。
这降低了代码的可维护性，包括我们在PMalk中最初采用的JS，然后使用react框架。
项目初期的团队为了加快速度，使用了开源系统进行了二次开发，但是为了以后的迭代、优化，埋下了定时炸弹。
现在前端开发的同学找到我，常说需求可以先放一放，重构优先吧。 现在的代码看起来太费时间了，所以先别换。
2 .业务发展不明确，产品结构混淆
早期的PMTalk还是一个提问的论坛，没想到最终会成为一个视频、兼职、体验报告为一体的互联网社区。
但实际上，探索新功能、业务定型和数据验证至少花了半年时间。
关注一下我的朋友，我一直在强调产品是业务的载体形态，但应该知道业务没有定型化自然会打乱产品的框架。
例如，我们认为自己不制作事件登录系统，只做第三者的事件跳跃。 在产品框架中只允许运营，用户通过平台跳转到第三方注册。
之后，从活动人数和用户可控性等方面来看，自己建立活动注册系统需要用户管理、活动管理的升级。
3 .业务逐渐定型，产品规划逐渐有向t型发展的趋势
一个互联网产品在三年后，其实可以说是“高龄”。 因此，此时产品框架已经形成了用户主要使用的路径，此时版本重构要求严格保留前期的核心功能，具有良好的边缘化
在用户体验的要素中，提到最底层、抽象的战略层，其实是t型发展的依据。 对于确定的业务不怎么变更
产品上线时间越长，越需要高凝聚、低偶联
回答开头提到的问题：
“一个产品在线三年后，需要解决什么问题？ ”
其方向是不断完善聚集核型功能，将个性化业务边缘化分解，使之成为非共同能力。
同时，一个产品正常运营三年，首先他的业务也在不断发展，内部员工也在增加，高增长的背后自然会出现开头的两类问题。
互联网产品也是一项软件工程，其高凝聚、低耦合要求我们在开发过程中紧密遵守。
各模块相互连接越紧密，耦合性就越高，模块的独立性就越差。 反之亦然。
再举一个例子：
一个项目中有20个方法调用良好，但需要修改其中一个，其他19个方法也需要修改。 这就是高耦合。 如果修改其中一个，再修改两个，就会产生低耦合。
通过这个案例可以看出，保持这样的软件方法可以大幅降低时间成本。
三年的时间里，产品不断迭代，从一个小应用发展到高级阶段，一个大工程，从头到尾都是不可能独自实现的，在那里分工模块化完成。
例如，PMTalk最初经历的是后端服务渲染，而现在出现的前后端分离是逐步发展分工。
即使是一个人完成的程序，只要在内部遵循MVC模式，subroutine就会完成各功能。 因此，模块化的开发要求高凝聚低结合。
MVC模式(Model-View-Controller )是软件工程中的一种软件体系结构模式，它将软件系统分为模型、视图、控制器三个基本部分
软件设计耦合的八种状态
在这里，我们收集了包括数据、功能、业务三个维度在内的常用耦合关系。 由此，能够判断是否为耦合
1 .无直接结合
这意味着两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用实现的。
2 .数据联接：
两个模块之间存在函数调用关系，指传递简单的数据值，相当于高级语言的传递
3标记结合：
指两个模块之间的传递是数据结构。 例如，作为数组名、记录名、文件名等名称的标记实际上传递了这个数据结构的地址。
4 .控制联轴器：
当一个模块调用另一个模块时，它会传递开关、标志等控制变量，协调模块根据该变量的值选择性地执行块中的功能
5、外联轴器：
一组模块访问所有相同的全局简单变量，并在不通过参数表的情况下传递该全局变量的信息，称为外部联接。 外部耦合与公共耦合非常相似。 不同之处在于一个是简单变量，另一个是复杂的数据结构。
6 .公共耦合：
指通过共同数据环境进行交互的模块之间的耦合。 公共耦合的复杂程序随耦合模块数量的增加而增加。
7内容合并：
>这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。
或许在年夜前还能在保持原创做内容，实际上已经不是一种任务了。而是变成一了一种定时输出。
趁着春节假期，我们团队也在发布弱小版本，尤其是移动端的小程序预计在春节也会上线。
我的个人微信：574319420，多交流