短篇小说。 我参与的项目中的某个人决定使用反射从另一个DLL访问另一个类的成员。为什么？懒惰。 我有一个很好的（坏的）习惯，在签入文件之前消除所有Resharper警告。 有一天，我看到一个私人成员在它所属的类中没有被使用过......所以，shift + delete和成员都没了。 两个月后，来自我们的一个生产基地的showstopper。 花了我们一个星期才发现问题是反射代码找不到私有成员，包装代码不够好。 实际上，这也是我们的自动测试未涵盖的情景。
您建议使用哪种代码分析工具来设置此类用例的规则？
由于
答案 0 :(得分：4)
没有工具，因为在DLL方面没有办法测试这个。
保留某些方法的原因是公开的，而某些方法是私有的，因此您可以使用已发布的合同，消费者可以使用DLL。你在DLL内部做的应该是一个黑盒子，没有人应该知道或关心发生了什么。
“测试”的唯一方法是在调用方面为任何使用反射的函数编写沼泽标准单元测试。然后，您必须确保DLL的发行版本与您对单元测试的版本匹配。
对于使用反思的人，让他证明他的理由是正当的，如果不合理则让他接受缓刑，要求他提交的所有代码在被允许登记之前进行更彻底的审查。如果他不停止做事像这样（当他绝对不应该使用反射，或者不通过单元测试编写必须使用反射的代码来确保他调用的代码在内部没有改变时） 他应该被解雇< / EM>