我知道盲目地遵循任何“最佳实践”仍然会导致一堆臭味，严格遵守最佳实践。 SOLID原则就是原理。它们并不适用于所有情况，但是对于在代码中寻找可能的改进，它们仍然是很好的启发法。
它们的缺点是它们有时需要对您的源代码进行深入的分析才能应用它们。我像大多数程序员一样，一直在寻找更有效的处理方式，因此，我很好奇是否有人听说过一种分析工具试图对SOLID原理的应用进行测试（或缺少SOLID原理）。
SRP 单一责任原理
一个班级只有一个理由更改。
OCP 开闭式原理
软件实体（类，模块，功能等）应该开放给扩展名，但因修改。
LSP Liskov替代原理
子类型必须可替换为他们的基本类型。
ISP 接口隔离原理
不应强迫客户依赖根据他们不使用的方法。接口属于客户端，不属于层次结构。
DIP 依赖反转原理
抽象不应依赖于细节。细节应取决于抽象。
-摘自敏捷原则，模式和实践
我认为自动静态分析不能确定是否遵守这些原则。要编写这样的工具，您需要正式定义每个概念的含义，并有一种方法可以对照任何代码对其进行检查。您将如何正式化责任概念？我个人不知道。
也就是说，您可以使用工具来检测违规的可能性。例如，您可以使用代码度量标准（例如每个类的方法数量，每个类的成员数量）来确定一个类是否太大，因此可能违反SRP。
[Liskov替代原则可能是例外。IF您可以在所有方法（前提条件，后置条件，不变式）上定义合同，然后可以检查重新定义超类方法的方法是否不会增强前提条件，不会削弱后置条件并尊重不变式超类的方法。我认为工具ESC/Java执行了这些检查。阅读wikipedia page about LSP，将需要执行更多检查。
我的答案涉及一个.NET特定的产品，事先道歉，也许有人可以建议其非.NET类似物。
我会尝试NDepend，看看它是否可以通过使用类似的指标使我违反SRP和ISP：
DIP和LSP违规可能更难追踪，因为它们涉及程序员的意图。分析工具可以识别类型之间的关系，但是如何判断一个类真正地从Square不适当地派生的Rectangle派生出另一类呢？或者，在一个经过适当设计的程序中，A应该依赖于B而不是相反的方式？
OCP提出了另一个挑战，因为不一定必须进行对类应该打开/关闭的扩展/修改。
但是，如果我们相信遵循SOLID可以带来更易于维护的产品（科学地证明这一主张不是这个问题的本质），那么NDepend的Abstractness-Instability图表应提供很好的aggregate
度量，以证明每个软件模块均遵循原则。如果是这样，则该模块应该避开图表的左下角，称为“痛苦区域”。在该区域中，模块是稳定的（不是很好的方式-太多模块依赖于它，因此很难更改），但不够抽象。