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