“设计债务”一词指的是您每次避免做正确的事情（例如重构，消除重复/冗余），从而导致代码质量随着时间的推移而恶化时，您承担多少债务。设计债务指标？
然而，当人们谈论测量设计的债务，人们经常谈论有Sonar kind of dashboard。现在，如果我们谈论Sonar等指标，那么除了复杂性之外，我认为其余指标更多地告诉您代码质量，而不是设计质量。我错过了什么吗？
是否有工具，措施（如为，使用模式，或正确使用的模式，或与此有关建议哪些模式可以通过分析代码中使用？）的设计质量。或者，这仍然是一门艺术而不是科学？
我认为衡量设计债务的好方法是使用JDepend（如果你使用的是Java;还有一个DOTNET当量）。
只计算模式的发生并不一定会有帮助。我已经看到了代码库，尽管它们严重受到模式感染，但代码仍然紧密耦合在一起写得很糟糕。在我看来，编写一种工具可以区分有用的模式和反作用的混淆模式 - 投掷是非常困难的。
无论如何，JDepend测量的是代码中的耦合量和独立性。因为这是模式应用的深思熟虑应该是一个非常有用的设计指标。
通常，从JDepend获得的数字需要进行一些分析，因为代码的不同部分应该对可接受的依赖关系有不同的期望，它不是一种将代码馈入并获取单个数字的工具评分整个代码库。
另一个有用的指标是cyclomatic complexity。它通过您的代码来衡量不同路径的数量，这很好地表明您的代码有多么复杂和复杂。代码覆盖率工具Cobertura生成圈复杂度统计信息。
没有一套标准将会给你你的代码的suckitude的客观测量。你的部分代码可能需要变得复杂，其他部分会有很好的依赖或耦合的原因，对于某些代码来说，如果它写的是垃圾，那么它可能并不重要。你可以做的是找到你可以用来检查你的期望的工具，以决定你的问题可能在哪里。
即使你能确定代码使用什么设计模式（这是绝对有意义的任务），你永远不能说他们是必要与否 - 这是设计质量有关。
我会尝试测量“概念密度” - 每行代码。可悲的是，我们无法自动判断哪些代码反映了具有商业价值的业务逻辑，哪些代码仅支持程序员的基础架构。这将衡量KISS的一致性。
软件设计的目的是使代码/架构可读人，所以我能想到的最好的事情是幽默的“每分钟的WTF”，这是符合最惊喜的原则。
OTOH，你可以尝试测量一些非常衍生的指标。我倒是名称：
一件事是有点容易衡量是Code Coverage。如果您的代码正在开发中，那么测试的百分比正在减少，这是一笔负债。
这仍然会告诉我有关代码质量而不是设计质量。不是吗？ – Nilesh 2011-02-18 14:45:31
某些源代码指标反映了设计质量。例如，传入/传出调用次数（NII/NOI），对象类之间的耦合（CBO），内聚缺乏（LCOM），DIT，RFC等等。显然，他们不会告诉你任何关于系统，但是，如果它们表现得非常好或者很好地“一起”，它可能反映了糟糕的设计。不幸的是，这些指标并不相互独立，改进一个方面可能导致另一方面变得更糟。因此，需要一个将这些度量标准合并为一个全球“部门”值的模型。我们的工具QualityGate使用此类模型来汇总高级质量值（它也是一个源代码可维护性，它也包含了设计方面）。该理论在于probabilistic software quality model的扎实基础。
那么当您需要测量设计债务时，您需要确定“设计气味”。根据检测到的设计气味的数量和确定的独特设计气味的数量，您可以估算设计债务。
设计气味检测工具使用各种指标（CBO，LCOM，DIT等）来识别气味。
书籍“Refactoring for software design smells: Managing technical debt”提供了一个全面的设计气味目录，这可能在这方面很有用。
JDepend似乎很有趣。对图案很好的想法。 – Nilesh 2011-02-18 14:10:10