快捷搜索:  汽车  科技

软件工程导论内聚和耦合:软件设计的高内聚

软件工程导论内聚和耦合:软件设计的高内聚2.业务发展的不明确,产品结构的混论以至于现在的前端开发同学找到我,经常会说需求可以先放下,我们优先做重构吧,现在的代码看着太费时间了,先别说改。而互联网团队的开发人员、产品经理一般在职时间1-2年会正常生命周期,在系统还没有变现下、或探索期人员经历大量的变动。所以代码的可维护性就越来越差,比如在PMalk我们早期采用的JS、后续才使用react框架。在项目早期团队为了快,使用开源系统做二次开发,但却为后面的迭代、优化埋下了定时炸弹。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件工程导论内聚和耦合:软件设计的高内聚(1)

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


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

回答开篇提到的问题:

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

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

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

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

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

再举个案例:

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

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

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

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

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

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


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

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

1.无直接耦合

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

软件工程导论内聚和耦合:软件设计的高内聚(2)

2.数据耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(3)

3 标记耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(4)

4.控制耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(5)

5,外部耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(6)

6.公共耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(7)

7 内容耦合:

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

软件工程导论内聚和耦合:软件设计的高内聚(8)

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

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

猜您喜欢: