[管理侧] 构建复杂度(Construction Complexity)理论:类型,

darkk
darkk体国经野 义尚光大 08月07日 字数 3524
loading ...

构建复杂度(Construction Complexity)理论:类型,组成和实例

(2021/8/7, 首发于水木社区 SoftEng 版)

1.编程复杂度和构建复杂度

========================

如果说时间复杂度(Time Complexity)和空间复杂度(Space Complexity)体现了软件的运行,是对软件的运行(Running)的一种尺度,那么构建复杂度(Construction Complexity)则强调软件的生成(Generating)的尺度。

在许多大公司里,一种衡量构建复杂度的变更的方法是“代码行数”。在这过去又通常被称为“软件复杂度”,但我们现在其实也知道,“软件复杂度”是多种方面的。在这个意义上,从概念来说,我们似乎有理由把构建复杂度、时间复杂度、空间复杂度都看为软件复杂度的某种实例,但构建复杂度更趋向于软件的存在,而时间复杂度、空间复杂度更趋向于软件的存在方式。

从直观来看,“代码行数”是深受认可反映构建复杂度的一个有意义的指标。显然,代码的行数越多,一个软件的构建(The Construction Of A Software)似乎就越复杂。但不要忘了,在今天,复制粘贴已经成为软件构建的重要方式。而更深层面的问题则在于,很多代码很精简,却需要付出很艰苦的思想。“代码行数”似乎可以反应某种体力劳动,却难以反应脑力劳动。

一个好的事情在于:完成构建了的软件,我们可以视为版本内不变的。这就意味着,我们不必研究构建复杂度的动态特性。我们不必用O(1),O(N^2),O(Nlogn)这些东西来研究,软件如何随着业务的增长,自己的构建、代码行数等等也增长。当然,这种研究或许也足以成为问题,但我们暂时不在这里讨论。

我们不妨把构建复杂度(Construction Complexity)分为静态复杂度(Static Complexity)和动态复杂度(Dynamic Complexity)。前者更关注软件的度量,而把软件的规模和构成视为不变的;后者更关注软件在时空中随着各种因素和条件的改变的动态过程,研究软件的规模和构成和各种因素的数理关系。

2.静态复杂度的四种类型:Type 0, Type 1, Type 2, Type 3

=======================================================

这里提出一个静态复杂度的模型,它来自我们的经验。这个模型主要从已有的技术实例,尚未解决的技术问题,需要满足的需求的程度,这四个类型来综合考虑构建复杂度——

◆ Type 0: 已经有相关的按钮、窗口、屏幕、产品、界面、服务、解决方案等等,没有任何代价和费用,不需要做任何事情,或者只需要点击鼠标,发发信息,下载安装包安装之类的操作,既可以满足所有的需求。

◆ Type 1: 已经有实例,只需要修改或者建立分支版本,或者基本上所有的技术已经有成熟的指导文档或成熟方式,明确已经有相关的需求的满足方式或代替品。

◆ Type 2: 已经没有数据交换、编码、解码的障碍(跟网络有关系),不存在算法的困难或者未能确定的部门,已经完成大部分组件或者缺少某一两个组件,没有能把各种组件和功能组合、继承起来的(可靠的)实例,或者有实例但难以根本地适用,关键的需要是否能满足也尚未验证。

◆ Type 3: 除了名字(甚至名字也不知道),什么可以复用的都没有,或者有但是不开放,或者开放但是实际上没几个人掌握,要求满足需要的程度非常高。

(图解/构建复杂度)

容易看到, Type 0 已经趋近于使用问题已经解决,相关工程已经实现。

随着从 Type 1 到 Type 2, Type 3,我们面临的未知更多,我们面临的不确定更大,某种程度上这样子的构建也就越困难。在不考虑工程实施主体的条件下,构建复杂度随着从 Type 1 到 Type 2, Type 3,越来越困难。

但我们也有一些启示。例如,软件公司可以通过渐进地了解不同的领域,逐渐把某种项目的构建复杂度从 Type 3 降解到 Type 1,进而实现生产力的自主掌握以及全业态发展。反过来说,软件公司也可以从Type 1出发,通过向 Type 3 前进,构建相关的生态,逐步实现可持续的开发能力的升级和进化。

3. 进一步的探讨

===============

这里似乎可以回到“软件成熟度”的问题,但我们实际上把“构建复杂度”提到了主题的地位。

构建我们可以从双层的意义上去理解:一方面,构建是成果,构建复杂度是对这种构建了的成果的复杂性的尺度;一方面,构建是过程,构建复杂度在研究完成构建目标所需要的费用和投入。

可能一些结论并不是在这里首次提出,也欢迎补充其他观点和要点。

SoftEng 软件工程
3 个回复
KCN
毒中之毒~strongest 08月09日

但这个构建复杂度主要是考虑单体应用吧。在微服务里面,依赖复杂度才是

影响构建的主要因素

【 在 darkk (darkk体国经野 义尚光大) 的大作中提到: 】

: 构建复杂度(Construction Complexity)理论:类型,组成和实例

: (2021/8/7, 首发于水木社区 SoftEng 版)

: 1.编程复杂度和构建复杂度

: ...................

licy
上网不便, msg收不到 08月16日

构建过程不应该有依赖吧,更多的是远程调用,不要紧耦合

【 在 KCN (毒中之毒~strongest) 的大作中提到: 】

:   但这个构建复杂度主要是考虑单体应用吧。在微服务里面,依赖复杂度才是

: 影响构建的主要因素

darkk
darkk体国经野 义尚光大 08月22日

不失一般性的,似乎

构建复杂度 = 依赖复杂度 + 职能性复杂度

还没想清楚,可能有问题 @_@

感觉这个如果能够说清楚,好像还挺漂亮的一个 formula 。。谢谢大家的启发!。。