我们都知道要保持简单，对吧？
我已经看到复杂性被衡量为系统之间的交互次数，我想这是一个很好的起点。除了直觉之外，还有哪些其他（最好是更客观的）方法可以用来确定特定设计或软件的复杂程度？
您最喜欢的规则或启发式方法是什么？
问问题
572 次
7 回答
3
这是我的：
1) 向了解问题但尚未考虑解决方案的人解释有多难？如果我向大厅里的某个人解释问题（如果他们在大厅里，他们可能已经理解了问题）并且可以解释解决方案，那么它不会太复杂。如果需要一个多小时，则很有可能解决方案过度设计。
2) 你必须在嵌套函数中走多远？如果我有一个对象需要由另一个对象持有的对象持有的属性，那么很有可能我正在尝试做的事情与对象本身相距太远。当试图使对象成为线程安全的时，这些情况会成为问题，因为从您当前的位置锁定许多不同深度的对象。
3）您是否正在尝试解决以前已经解决的问题？并非每个问题都是新问题（有些人会争辩说实际上没有）。您可以使用现有的模式或模式组吗？如果你不能，为什么不呢？制作自己的新解决方案很好，我完全赞成，但有时人们已经回答了这个问题。我不打算重写 STL（尽管我曾经尝试过），因为解决方案已经存在并且是一个很好的解决方案。
于 2008-10-31T15:03:50.230 回答
3
当我参加新英格兰复杂系统研究所 ( http://necsi.org/ ) 的复杂系统建模研讨会时，他们使用的衡量标准之一是系统状态的数量。
例如，如果您有两个交互的节点 A 和 B，并且每个节点都可以是 0 或 1，那么您可能的状态是：
A B
0 0
1 0
0 1
1 1
因此，二进制组件之间只有 1 次交互的系统实际上可以导致 4 种不同的状态。关键是系统的复杂性不一定会随着交互次数的增加而线性增加。
于 2008-10-31T15:04:17.343 回答
3
可以通过耦合以及所有对象的内聚性来估计复杂性。如果某些东西有太多的耦合或不够内聚，那么设计将开始变得更加复杂。
于 2008-10-31T15:07:14.700 回答
1
好的措施也可以是文件的数量、配置存储位置的数量、某些语言的编译顺序。
例子：
.- 属性文件、数据库配置、保存相关信息的 xml 文件。
.- 数以万计的具有接口和数据库映射的类
.- 一个非常长且复杂的构建文件（build.xml、Makefile、其他..
于 2008-10-31T15:11:55.347 回答
0
最后，LOC 可以真正帮助测量的东西吗？:)
我认为复杂性最好被视为需要交互的事物的数量。
复杂的设计有 n 层，而简单的设计只有两层。
需要复杂性来解决简单性无法克服的问题，因此它并不总是一个问题。
通常定义复杂性存在问题，因为复杂性通常具有与之相关的任务。有些东西可能理解起来很复杂，但看起来很简单（例如非常简洁的代码） 将此网页从服务器获取到您的计算机的交互次数非常复杂，但 http 协议的抽象非常简单。
因此，在选择测量之前考虑一项任务（例如维护）可能会使其更有用。（即添加一个配置文件并将日志记录到应用程序会增加其客观复杂性[是的，只是有点确定]，但简化了维护）。
于 2008-10-31T19:08:02.233 回答
0
如果您的应用程序已构建，您可以根据时间（执行特定任务需要多长时间）或计算量（每次运行任务时执行多少代码）来衡量它。
如果您只有设计，那么您可以查看运行给定任务或运行普通任务需要多少设计组件。例如，如果您使用 MVC 作为您的设计模式，那么您至少需要 3 个组件来处理大多数任务，但根据您的设计实现，您最终可能会使用几十个组件（除了例如 3 层）。
于 2008-10-31T15:00:56.677 回答
-1
于 2008-10-31T15:29:27.650 回答