「設計債務」一詞指的是您每次避免做正確的事情（例如重構，消除重複/冗餘），從而導致代碼質量隨着時間的推移而惡化時，您承擔多少債務。設計債務指標？
然而，當人們談論測量設計的債務，人們經常談論有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