在评估设计时,如何评估复杂性?[关闭]

这是我的:

1)向一个理解问题但没有考虑解决方案的人解释有多难?如果我把问题解释给大厅里的人(如果他们在大厅里的话,他们可能已经理解了这个问题)并且能够解释解决方案,那就不太复杂了。如果超过一个小时,很有可能解决方案被过度设计了。

2)嵌套函数的深度是多少?如果我有一个对象需要一个由另一个对象持有的对象所持有的属性,那么很有可能我试图做的事情与该对象本身相距太远。当试图使对象线程安全时,这些情况会变得有问题,因为从当前位置到锁定位置会有许多不同深度的对象。

3)你想解决以前已经解决的问题吗?并不是每个问题都是新的(有些人会争辩说没有一个是真的)。您是否可以使用现有的模式或模式组?如果你不能,为什么不呢?自己制定新的解决方案是很好的,我也很支持,但有时人们已经回答了这个问题。我不打算重写stl(尽管我曾经尝试过),因为解决方案已经存在,而且是一个很好的解决方案。

复杂度可以用 耦合 以及如何 有结合力的 都是你的东西。如果有些东西有太多的耦合或者没有足够的内聚性,那么设计就会变得更加复杂。

当我参加新英格兰复杂系统研究所的复杂系统建模研讨会时( http://necsi.org/ ,它们使用的度量之一是系统状态的数量。

例如,如果有两个相互作用的节点A和B,并且每个节点都可以是0或1,则可能的状态为:

A B
0 0
1 0
0 1
1 1

因此,一个二元组分之间只有一个相互作用的系统实际上可以导致4种不同的状态。关键是系统的复杂性不一定随交互次数的增加而线性增加。

好的度量方法还可以是文件的数量、存储配置的位置的数量、某些语言的编译顺序。

实例:

.-属性文件、数据库配置、保存相关信息的XML文件。

-数以万计的带有接口和数据库映射的类

-一个非常长且复杂的生成文件(build.xml、makefile和其他..

如果你的应用程序是构建的,你可以用时间(一个特定的任务执行需要多长时间)或计算(每次任务运行时执行多少代码)来衡量它。

如果您只有设计,那么您可以查看运行给定任务或运行平均任务需要多少设计组件。例如,如果使用mvc作为设计模式,那么对于大多数任务,至少有3个组件被触及,但是根据设计的实现,最终可能会有数十个组件(例如,除了3层之外的缓存)。

最后,loc可以帮助测量的东西?:)

我认为复杂性最好被看作是需要相互作用的事物的数量。

一个复杂的设计有n层,而一个简单的设计只有2层。

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

一般来说,在定义复杂性时存在一个问题,因为复杂性通常有一个与之相关联的任务。 有些东西可能很复杂,但很容易理解(例如非常简洁的代码) 将此网页从服务器发送到计算机的交互次数非常复杂,但是http协议的抽象非常简单。

因此,在选择一项措施之前考虑一项任务(如维护)可能会使其更有用。(例如,添加配置文件并登录到应用程序会增加其目标复杂性[是的,只是有点确定],但会简化维护)。

有正式的标准。读起来 Cyclomatic Complexity ,例如。

编辑。

还有,看看 Function Points . 它们给你一种非直觉的系统复杂性定量测量。