我们都知道要保持简单，对吧？
我看过一些把复杂度定义为系统间交互次数的方法，我认为这是一个很好的起点。但除了凭感觉以外，还有什么其他（最好更客观的）方法可以用来确定特定设计或软件的复杂程度呢？
你们喜欢使用哪些规则或启发式方法呢？
7个回答
3
当我参加新英格兰复杂系统研究所（http://necsi.org/）的复杂系统建模研讨会时，他们使用的一项措施是系统状态的数量。
例如，如果您有两个节点A和B进行交互，并且每个节点可以是0或1，则可能的状态为：
因此，仅在二进制组件之间进行1次交互的系统实际上可以产生4种不同状态。重点是，系统的复杂性并不一定随着交互数量的增加而线性增加。
例如，如果您有两个节点A和B进行交互，并且每个节点可以是0或1，则可能的状态为：
A B
0 0
1 0
0 1
1 1
因此，仅在二进制组件之间进行1次交互的系统实际上可以产生4种不同状态。重点是，系统的复杂性并不一定随着交互数量的增加而线性增加。
- lfalin
3
以下是我的回答：
1) 如果我向大厅里的某个人解释问题（如果他们在大厅里，可能已经理解了问题），并且能够解释解决方案，则说明问题不太复杂。如果需要一个多小时，那么解决方案可能过度设计。
2) 你需要嵌套多少函数？如果我有一个对象需要访问另一个对象中的属性，而这个对象又被另一个对象持有，那么很可能我离对象本身太远了。当尝试使对象线程安全时，这些情况会变得棘手，因为从当前位置到锁定的对象可能有许多深度不同的对象。
3) 你是否试图解决已经解决的问题？并非每个问题都是新问题（有些人甚至认为没有一个是新问题）。是否有现有的模式或一组模式可以使用？如果不能使用，为什么不能？制作自己的新解决方案很好，我完全支持，但有时候别人已经解决了问题。我不会重新编写STL（虽然曾经尝试过），因为已经有解决方案，并且是一个好的解决方案。
- mmr
3
复杂度可以通过耦合度和所有对象的内聚性来估计。如果某些东西具有过多的耦合度或不足够的内聚性，那么设计将开始变得更加复杂。
- Daok
1
良好的度量也可以是文件数量、配置存储位置数量，以及某些语言编译的顺序。
例如：
- 属性文件、数据库配置、保存相关信息的 XML 文件。
- 数以万计的带有接口和数据库映射的类。
- 极其长且复杂的构建文件（build.xml、Makefile 等等）。
例如：
- 属性文件、数据库配置、保存相关信息的 XML 文件。
- 数以万计的带有接口和数据库映射的类。
- 极其长且复杂的构建文件（build.xml、Makefile 等等）。
- webclimber
1
不是代码的复杂性，而是设计的问题，很难在设计时知道有多少文件 ;) - Patrick Desjardins
0
如果您的应用程序已经构建完成，您可以根据时间（执行特定任务所需的时间）或计算量（每次运行任务时执行了多少代码）来衡量它。
如果您只有设计，那么您可以看看运行给定任务或运行平均任务所需的设计组件数量。例如，如果您使用MVC作为设计模式，那么对于大部分任务，您至少需要涉及3个组件，但是取决于您实现设计的方式，您可能会得到数十个组件（例如，缓存除了3层之外的其他组件）。
- Elie
0
终于有些东西 LOC 真的可以帮助衡量了？:)
我认为复杂性最好被视为需要相互作用的事物数量。
一个复杂的设计会有 n 层，而一个简单的设计只会有两层。
复杂性是为了解决简单性无法克服的问题而需要的，所以它并不总是一个问题。
一般来说，定义复杂性存在问题，因为复杂性通常与任务相关联。 某些东西可能在理解上很复杂，但在外观上很简单（例如非常简洁的代码）。 将此网页从服务器传输到您的计算机的交互次数非常复杂，但 HTTP 协议的抽象非常简单。
因此，在选择度量标准之前考虑任务（例如维护）可能会使其更有用。（即向应用程序添加配置文件和日志会增加其客观复杂性[是的，只有一点点确定]，但简化了维护工作）。
- Nat
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接