如何衡量软件系统的复杂度(一)

一、背景

自从Eric的书名中提到如何应对软件复杂度的问题，后面的很多其他大佬都在尝试用自己的方式来阐述软件复杂度和如何应对软件复杂度。但是我们可能忽略了一个基本的问题就是我们如何衡量它。在软件架构工程中有一些复杂度函数，比如neal的适应度函数等。比如一些衡量耦合相关的指标和数学函数信息，但是这只是整个软件工程中的某个方面的复杂度的信息，对大多数软件从业者来说，这显得有点专业了。

本系列将尝试通过3-4篇文章来相对全面的讨论这个问题，同时也希望用一些相对简单的衡量指标来构建一个模型，让这个复杂度可以有个简单的量化过程。当然如果我数学足够好，或许这个系列会更精彩，不过你依然可以期待这个话题相关的内容。

二、复杂的原因

这里我们简单看一下软件本身变得复杂的一些原因。从宏观层面可以感受一下整个软件行业或者计算机编程领域的复杂度。

2.1 软件在不同领域的深度应用

熟悉计算机或者比较早接触编程的人肯定都知道，从打孔机到计算机的演进变化，随着计算机体系架构的确定和传播，软件早已在不同行业不同场景中得到了一些发展，比如军工领域，网络，银行股票交易，操作系统。当然到现在的互联网+。提到现在的数字化转型肯定也听过之前的信息化，所以现在我们做很多事情可能都需要软件的辅助工作。
在CSDN等老牌技术博客网站就可以看出整个软件领域已经被分割的比较细了，比如操作系统，网络，算法，嵌入式，云计算，云原生等等。所以这里可以发现软件的不同领域是越学越多，越学越觉得需要懂的东西越多。这跟整个餐饮厨师行业有很大的相似度，只是说这个发展过程变得快很多。在厨师这个职业一个人不可能精通各类做饭的技术，当然，在软件研发领域一个人也不可能精通各类软件研发技术。

上面的思维导图是我从CSDN的主页里参考的，如果细化的话可能还有更多内容，也就是说软件研发已经形成了一个很大的体系了，所以复杂性自然而然从90年代到现在也是呈爆发性提高的。

2.2 技术栈和语言的多样性

早期的技术语言肯定都听说过B,VB等低级语言，后来有了C，然后就是C++,Python,Java等等。这些语言在不同的时代不同的场景都解决了对应的问题，同时从语言层面来说，创建一门语言的用处会比创建一个中间件的用处广。当然这里可能不是一个维度的事情，由于计算机本身的体系结构决定了，越高级的语言离底层越远，所以其复杂度越高，其他的方面可能就越低。所以从语言上来看，软件研发的相关语言已经有200多种了。自然而然的基于多个语言或者单一语言来构建的软件工具形成的技术栈也变得非常多，此时就像百家争鸣一样，或者说百花齐放。比较秀的是可以用不同的语言写helloworld。但是从从业者本身的角度来说helloworld仅仅只是开始。
这里的技术栈就是我们开发软件经常使用的软件工具或者开发包SDK等，以前开发软件可能不需要联网，但是现在的话开发软件不联网可能会很痛苦，从工具中体现的多样性说明了我们现在开发一个应用软件需要的知识和对工具的使用要更加熟练，要有合适的深度。
既然技术栈和语言的多样性现在已经存在了，所以很多人都感慨“一入编程深似海,从此妹子是路人”。

2.3 计算机体系结构与协议

从冯诺伊曼体系来看，现在很难会推翻当前的计算机系统架构内容。我们从最近的芯片话题可以看出，也许将来会有更厉害的计算机体系。话说回来，自从有了计算机，就有了图形化界面，和打字输入输出设备。所以相应的底层软件也都被集成到计算机系统和网络维度。这些都是比较基础但是不需要使用人员过多了解的东西。
从从业者的角度来说，知道计算机组成原理，知道网络协议则可以更好的设计出软件来解决问题。但是这也为整个软件研发造成了一些复杂度，因为一些很深或者很奇怪的bug通常不是应用层面的，有可能来自操作系统或者网络配置。那对于开发者来说经常遇到这样的问题可能会极度崩溃。通常来说在早期的一些软件研发过程中没有网络，信息相对闭塞的时候排查问题可能会需要一个月两个月或者更久。
所以，现在，如果开发一款软件联网可能是基本操作，会Google是另一项基本操作。

2.4 需求本质的复杂性

现在我们来看一下这两个问题:

1. 软件开发开发的是什么？

2. 软件开发解决的是什么？

   这看上其实没多难，产品说开发的是软件产品啊，技术说开发的是代码啊，这都对，解决的当然就是现实的需求。所以很多时候我们想做一个游戏或者应用其实就是需求，当然这肯定有点难度，从需求到软件发布，中间可能会经过多个过程，不管是单人还是团队开发都需要了解更多的内容，包括一些软件之外的知识能力。
   当然某个想法或者某个现实问题通过计算机软件来完成的时候，就变得复杂了，这需要一些理解和学习的过程。到现在，产品经理与研发同学的相爱相杀更能体现这个话题，所以正规的软件研发过程肯定有一个可行性分析，从可行性分析就可以看出整个需求是否可以用计算机编程来解决以及怎么解决。

2.5 人本身的复杂性

这个方向怎么跟软件复杂度有关系呢，其实说白了，软件是人开发的。不同的人开发相应的软件都会带来不同程度的复杂度。同时因为一些利益和工作时间，团队合作等因素也会影响到整个软件的复杂度，比如加人，倒排期，主观上推倒重来等等。人是比较多变的，思维灵活，所以软件也会呈现动态化的复杂度。

三、复杂的系统

这里我简单的把各个行业内的复杂系统做了一些分类，通过这些系统的开发，使用和相关的行业来看其复杂性。

3.1 底层控制和驱动系统

这里的底层控制系统和驱动系统说的是操作系统和软硬件之间的系统，比如CPU，寄存器，驱动等等。在Linux则会有很多此类相关的系统。
另外一方面也包括一些嵌入式软件系统，类似于电子机床控制，或者飞机控制系统等等。这些系统更多的是通过电路板和相关的控制信号和线路组成，当然还有一些传感器等硬件设备。
所以在设计一个偏硬件方面的控制系统的话就需要知道很多软硬件的知识，以及如何看懂电路图，设计电路。

3.2 工业级软件系统

我将一些可以用在大规模商业的软件称为工业级软件，比如出现制裁的一些软件。这些软件依靠比较好的技术能力和市场占有率等有很大的盈利空间。这些工业级软件也是基础软件的一种，其可替代性比较小，当然，开发难度也大，所以复杂性就很高。

3.3 大型复杂网络系统

现在大型分布式网络系统已经不再稀奇了，国内外的大型社交网站，电商网站等等都算大型复杂网络系统。这些系统通常来说不是一个软件，而是由很多软件系统共同构建完成。所以其复杂性体现在规模庞大，链路长，强依赖网络和基础设施等。

四、不同视角的复杂度

4.1 软件需求设计人员

1. 需求对UI要求比较高
2. 需求对交互体验要求比较高
3. 需求对性能要求比较高
4. 需求对安全性要求比较高
5. 需求实际难以实现
6. 需求业务流程比较长
7. 需求规则比较复杂

4.2 软件开发者

1. 需求难以理解
2. 实现需要特定开发环境和开发包
3. 需求需要多种语言才能完成
4. 代码测试和重构比较困难
5. bug难以复现
6. 需求量大，开发时间长
7. 经常需要团队合作才能完成开发
8. 需求经常变化

4.3 软件使用用户

1. 软件有bug
2. 软件交互太复杂
3. 软件UI设计丑陋
4. 软件性能太差
5. 软件只能在特定的机器环境运行

4.4 软件拥有者

1. 软件具有知识产权和垄断能力，提高盈利能力
2. 软件太过复杂，可用性不行，流失用户

五、总结

本篇文章是关于软件领域整体复杂度的介绍，从不同方面感受下软件复杂度和相关领域因素，就目前看软件研发领域已经分的很细了，可能对于软件复杂度的理解也不一样。我本身也是在互联网企业做中台，主要偏微服务应用层的，其他领域了解很少。不过对于复杂度而言，不同的领域详细的复杂度因素对于软件的影响比重是不一样的，这会在后面几篇文章讲到，敬请期待。