软件设计的复杂度

以你之姓@ 2022-08-08 03:22 85阅读 0赞

# 什么是软件设计的复杂度 #

软件技术发展的使命之一就是控制复杂度(Complexity)。从高级语言的产生，到结构化编程，再到面向对象编程、组件化编程等等。关于复杂度的定义并不一致，想要详细了解的可以读读[The Many Faces of Complexity in Software Design][].

英文中Complex和Complicated有着微妙的不同。但总结起来，软件复杂度偏负面意义，包括两个要点:  
\- 难以理解 (难以维护和扩展。)  
\- 无法预测行为

复杂度是随着软件规模不断扩大而必然产生的。它本身又是一个相对的概念，同一个系统对于设计者、开发者，以及维护者而言，复杂度是不同的。不同时期，一个程序员所能掌握的复杂度也是不同的，这也是一个程序员不断提升的目标。

既然业界已经对抗复杂度几十年了，我们就来整理一下。

# 以分解降低复杂度 #

以分解的方式进行的设计，主要特点是:  
\- 分离职责(Seperation of Concerns,参考单一职责原则)  
\- 关注接口(定义交互)

这是最常使用的技术了。将一个大问题，不断的拆解为各个小问题进行分析研究，然后再组合到一起。在西方称为Divide and Conquer Principle (分而治之原则)。

在结构化编程的时代，提倡模块化(Modularization)。最早提出软件复杂度的工程师提出了基于组件的软件(Component Based Software)。不知道是不是从乐高积木上得到的启发，将系统中拆分为不同的组件，各自实现，然后再组装在一起。

在架构设计中，无论是C/S风格，分层，还是N-Tier,SOA，和前面组件式一样，都是在进行分解,它们都更加强调组合交互。设计上，分分职责，定义好接口，就可以各自开发了。然后将交互限定于接口层，就能够很好的控制整个系统的复杂度。

比如应用层使用一个语音库(Speech Library,一个以库的形式的模块化应用), 根本不用关心其内部实现，只要了解如何使用它的API就可以了。

# 改善低赖降低复杂度 #

改进依赖关系的要点:  
\- 无环形依赖  
\- 稳定依赖原则（SDP）

分解可以降低系统层级的复杂度，但还有一种复杂度无法解决，即依赖的问题。这在[敏捷软件开发：原则、模式与实践][Link 1]中关于依赖性的讨论很详细。当参与者增加时，交互就会随之变得复杂。而当前的软件规模，系统中的各类SDK的API, Framework的API, 各种第三方库越来越多，模块间的依赖就会越来越复杂。  
![cycle\_dependencies][cycle_dependencies]  
显然系统中的模块或者组件太多了，需要进一步整理。但真正的问题在于出现了双向和环形的依赖。比如上图中负责计算的Computing模块也依赖到了UI模块，或许是因为UI层持有一个计算所需的关键参数。如果UI层变更，就可能会影响到Computing，出现无法预测的行为，给客户以不稳定的印象。

所以模块间的依赖关系必须简化，绝对不能出现环形的依赖。以Chromium为例，它对各个模块的依赖就有严格的定义，并且有DEPS在编译期保证程序员不会犯错。下图是Chromium Component依赖关系的定义，其中Component内部目录的依赖关系也有定义:  
![chromium\_component][chromium_component]

当底层模块需要依赖上层模块的实现时，就要通过依赖倒置(DIP)来处理。简单而言就是由底层模块定义一个接口，要求上层模块实现并注入到底层模块。  
![DIP][]

# 使用抽象降低复杂度 #

人的学习过程最有效的一种方式就是归类，其中运用的就是抽象思维。面对变幻无常的天气，人类通过对云的形状进行抽象，就可以预测天气变化。这里有一个抽象建模的过程。

抽象并不是面向对象语言专属，其实它和语言无关，本质上是一个思考的方式。它和分离的最大区别在于，抽象强调将细节隐藏，只关注核心的本质。而后者则重视于细节问题的分解和组合。

以求固定两点的最快捷路线为例。从分离的角度来，可以分解为以下问题:

> 1.  步行需要多少时间?
> 2.  乘公共交通多少时间？
> 3.  乘的士多少时间?
> 4.  组合以上答案，再评估哪一个最快捷的方式。

而从抽象的角度来看，解决的思路会是这样的:

> 遍历所有可能的交通工具，取耗时最小的:  
> 1. 步行  
> 2. 乘公共交通  
> 3. 乘的士

先给出一个抽象的解决思路，至于细节，则是进一步的实现。抽象最大的威力在于它比实现要稳定，也最能用于固化核心设计。在开发过程中，常常围绕着各种细节讨论，似乎抽象过于虚。但是如果没有以抽象来建立系统的设计全景，有些讨论将变得效率低下。

在[敏捷软件开发：原则、模式与实践][Link 1]中，Martin大叔简单的用抽象类在总类个数中的占比作为抽象性的度量，再结合稳定性的度量，用来评估设计。详情可以参考[组件设计原则之概念篇（三）][Link 2]。

# 以通俗原则降低复杂度 #

设计和实现时引入不必要的抽象或分解，也是一种复杂度．考虑扩展性也是确定会发生的需求才要考虑进来，否则就是引入不必要的复杂性．这也是敏捷设计所倡导的．  
一些约定俗成的命名，常常隐含着设计．比如Observer, Client, Adapter等等．我们要学习这些模式，也要准确加以命名．否则很容易造成理解上的问题．

# 小结 #

软件设计是一个平衡的过程，软件的复杂度决定着系统的可维护性、可扩展性和灵活性。我们再来回顾一下前人定义出软件设计的三原则:模块化、抽象和信息隐藏。McCabe也曾有论文专门讨论将圈复杂度应用度量设计的复杂度，不过已经历史久远。现在来看以依赖关系来评估设计的复杂度会更为有效。有兴趣可以了解一下[CppDepend][]。另外Google的工程师则基于LLVM IR也实现了一个工具用于依赖关系分析（[Generateing Precise Dependencies for Large Software][]）。

转载请注明出处: [http://blog.csdn.net/horkychen][http_blog.csdn.net_horkychen]

[The Many Faces of Complexity in Software Design]: https://repository.royalholloway.ac.uk/file/7e175821-b603-a854-f4f1-26946a520b1f/7/CC_Fiadeiro_paper.pdf
[Link 1]: http://www.amazon.cn/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91-%E9%A9%AC%E4%B8%81/dp/B00116MMA8/ref=sr_1_1?ie=UTF8&qid=1430325599&sr=8-1&keywords=%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%EF%BC%9A%E5%8E%9F%E5%88%99%E3%80%81%E6%A8%A1%E5%BC%8F%E4%B8%8E%E5%AE%9E%E8%B7%B5
[cycle_dependencies]: /images/20220805/5f5b96ea105b4521a321647122b12bc6.png
[chromium_component]: /images/20220805/7458db48b03a42eb9abf340cf1fd039c.png
[DIP]: /images/20220805/40135509de68420b86d9ad853938f4fd.png
[Link 2]: http://blog.csdn.net/lovelion/article/details/8540308
[CppDepend]: http://cppdepend.com/features
[Generateing Precise Dependencies for Large Software]: http://www.sei.cmu.edu/library/assets/presentations/wang-mtd2013.pdf
[http_blog.csdn.net_horkychen]: http://blog.csdn.net/horkychen