在评估设计时，您如何评估复杂性？

Question

我们都知道要保持简单，对吧？

我看到复杂性被衡量为系统之间的交互次数，我想这是一个非常好的起点。除了直觉之外，还有什么其他（最好是更客观的）方法可以用来确定特定设计或软件的复杂程度？

您最喜欢的规则或启发式是什么？

Answer 1

这是我的：

1）向了解问题但未考虑解决方案的人解释有多难？如果我向大厅里的某个人解释这个问题（如果他们在大厅里可能已经理解了问题）并且可以解释解决方案，那么它就不会太复杂。如果花费超过一个小时，那么解决方案过度工作的可能性很大。

2）你必须在嵌套函数中有多深？如果我有一个对象需要由另一个对象持有的对象持有的属性，那么我正在尝试做的事情远离对象本身的可能性很大。当尝试使对象具有线程安全性时，这些情况会成为问题，因为从当前位置到锁定会有许多不同深度的对象。

3）您是否正在尝试解决之前已经解决过的问题？并非每个问题都是新的（有些人会认为没有问题）。是否存在可以使用的现有模式或模式组？如果你不能，为什么不呢？制作自己的新解决方案一切都很好，我全力以赴，但有时人们已经回答了问题。我不打算重写STL（虽然我曾尝试过，但有一次），因为解决方案已经存在并且它是一个很好的解决方案。

Answer 2

当我参加新英格兰复杂系统研究所（http://necsi.org/）的复杂系统建模研讨会时，他们使用的一项措施就是系统状态的数量。

例如，如果您有两个交互的节点，A和B，并且每个节点都可以是0或1，则可能的状态为：

A B
0 0
1 0
0 1
1 1

因此，二元组件之间仅一次交互的系统实际上可以产生4种不同的状态。关键是系统的复杂性不一定随着交互次数的增加而线性增加。

Answer 3

复杂性可以通过耦合进行估算，内聚如何是您的所有对象。如果某些东西有太多的耦合或没有足够的凝聚力，那么设计将开始变得更加复杂。

Answer 4

好的措施也可以是文件数，存储配置的地方数，某些语言的编译顺序。

示例：

.-属性文件，数据库配置，用于保存相关信息的xml文件。

.-成千上万个带接口和数据库映射的类

.-一个非常漫长而复杂的构建文件（build.xml，Makefile，其他..

Answer 5

如果你的应用程序是构建的，你可以根据时间（特定任务执行需要多长时间）或计算（每次运行任务时执行多少代码）来测量它。

如果您只是设计，那么您可以查看运行给定任务或运行平均任务所需的设计组件数量。例如，如果您使用MVC作为您的设计模式，那么您在大多数任务中至少触及了3个组件，但根据您的设计实现，您最终可能会遇到许多组件（除了例如，3层。

Answer 6

最后LOC可以帮助衡量吗？ ：）

我认为复杂性最好被视为需要互动的事物的数量。

复杂的设计有n层，而简单的设计只有两层。

复杂性 需要解决简单无法克服的问题，所以它并不总是一个问题。

在定义复杂性方面存在一个问题，因为复杂性通常具有与之相关的任务。 有些东西可能很难理解，但很容易看（例如非常简洁的代码） 将此网页从服务器连接到您的计算机的交互次数非常复杂，但http协议的抽象非常简单。

因此，在选择度量之前考虑任务（例如维护）可能会使其更有用。 （即添加配置文件并登录到应用程序会增加其客观复杂性[是的，只是有点确定]，但简化了维护）。

Answer 7

有正式的指标。例如，请阅读Cyclomatic Complexity。

---

编辑。

另外，请看Function Points。它们为您提供了系统复杂性的非直觉定量测量。