短篇故事。我参与的一个项目中的某个人决定使用反射从另一个 DLL 访问另一个类的成员。为什么？懒惰。我有一个很好的（坏的？）习惯，即在签入文件之前消除所有 Resharper 警告。有一天，我看到一个私人成员在它所属的班级的任何地方都没有使用过……所以，shift+delete，这个成员就消失了。两个月后，我们的一个生产基地出现了一位大咖。我们花了 1 周的时间才发现问题是反射代码找不到私有成员并且包装代码不够好。碰巧，这也是我们的自动测试未涵盖的场景。
您推荐哪种代码分析工具，我可以在哪里为此类用例设置规则？
谢谢
没有工具，因为无法在 DLL 方面对此进行测试。
保留某些方法是公开的，而某些方法是私有的，原因是您可以拥有一个已发布的合同，供使用您的 DLL 的人使用。您在 DLL 内部所做的应该是一个黑匣子，没有人应该对正在发生的事情有任何了解或关心。
为此“测试”的唯一方法是在调用方为任何使用反射的函数编写沼泽标准单元测试。然后，您必须确保 DLL 的发布版本与您进行单元测试的版本相匹配。
至于使用反射的人，让他证明他的理由，如果不令人满意，让他试用期，要求他提交的所有代码在允许签入之前进行更彻底的审查。如果他不停止做这样的事情（要么在绝对不应该使用反射的情况下使用反射，要么不为他的代码编写单元测试，必须使用反射来确保他调用的代码没有在内部发生变化）他应该被解雇。