复杂度度量方法及统合设想

知人者智，自知者明。

—老子，《道德经》

软件设计中的一个根本困难在于，并无明确的尺度来度量一种设计方案是好是坏，而只能依赖于判断。好比说在某个软件中，设计人员有意使用Factory模式，那究竟有什么办法可以判定这是一次误用，还是确实解决了问题；怎么判定程序使用了这个模式后是变简单了还是变复杂了。这很滑稽，我们一直说软件要降低复杂度，但我们并不能清楚地知道应用某种措施后，复杂度是不是被降低了。这种时候，一切就只能依靠是个人偏好，而偏好会引起误用和纷争。

接下来我们将探讨一种对设计或编码进行度量的方法，我们认为软件设计的根本目的是降低复杂度，所以一切说明从复杂度开始。在对复杂度进行讨论之前，我们有必要区分一下复杂度和难度。

假如我们需要把一份数据压缩到原来大小的10%，而当前算法只能压缩到50%，需要进一步研究和提升。这不是件容易的工作，但这类问题体现的是难度。

假如有一个函数很简单，刚会编程的人也能完成，但同样难度的函数却有10万个。这不是一件容易的工作，这里体现的则是复杂度。(www.xing528.com)

软件所面临的主要问题是尽可能降低复杂度，而非难度。难度与生俱来，虽然也影响项目，但往往更适合组织少数人进行突破。而且，非研究性项目中也不适合包含很多难度比较高的问题。

这样的话，如果我们有一种方法可以度量实现后的代码的复杂度，那我们就可以对设计和编码的好坏做一点量化的评价。

比如，功能点与具体实现细节无关，基本上是直接基于需求的估算，这样我们最终得到软件的规模可能是300功能点。

如果我们也找到了一种方法来实测软件的整体复杂度，并且知道300功能点的软件，实现复杂度大致应该在100～120之间，那么复杂度小于100的很可能是优秀的设计编码，大于120的很可能就是低劣的设计编码。

在接下来的章节里，我们先快速回顾一下当前与度量设计复杂度的相关方法，接下来提出一种统合复杂度度量的设想。