在C＃中，应该考虑在类之前多少行重构？
一个好的经验法则是我智能地重构超过50行的任何方法。
计数不包括注释和空格，而是实际代码。 我之所以聪明地说，有很多时候，超过50行的课程是可以接受的，不能或不应该改变。
我对课程没有经验法则。 一般来说，我不检查类是否应该重构。
在我目前的项目中，我刚刚完成了一个近4000行的课程。 然而，没有超过50的方法，并且大多数行和方法是私有的，并且不对类外的任何数据起作用。
重构类的经验法则是什么？
当class级违反SRP时 ，是时候重构了。
如果您的课程违反了以下“规则”之一，您应该考虑重构。
您正在寻找SOLID ，可在此处找到更详细的截屏video。
-
S RP：单一责任原则，一个class级改变的理由永远不应超过一个。
-
O CP：开放封闭原则，软件实体（类，模块，function等）应该是可以扩展的，但是关闭以进行修改。
-
L SP：liskov替换原则，使用对基类的引用的函数必须能够在不知道的情况下使用派生类的对象。
-
I SP：接口隔离原则，客户端不应该被迫依赖于他们不使用的接口。
-
D IP：依赖倒置原则：
-
高级模块不应该依赖于低级模块。 两者都应该取决于抽象。
-
抽象不应该依赖于细节。 细节应取决于抽象。
-
不要让LOC成为您的主要指标。 对我来说50条线看起来真的很小。 使用50行文件，您最终会在解决方案中拥有不合适数量的类文件。 您在文件之间进行的所有导航都会降低您的工作效率，您的IDE将始终充斥着太多标签。 我个人尝试先按名称空间将类组织成逻辑组。 在逐个类的基础上，我尝试使代码更小，更容易阅读。 有时，类文件会变大。 当类文件是2000多行时，我开始感到恶心。 除此之外，我会根据具体情况处理。
我不会说重构大型课程有任何“经验法则”。 有时候，一个类真的封装了很多业务逻辑，应该尽可能大。 但是，您可以考虑问自己一些问题：
-
（假设您正在编写面向对象的代码）我的代码是否真的面向对象？ 也就是说，它是否遵循单一责任原则（谢谢，Nebakanezer）？ 这个class是帮助class吗？ 如果是这样，我怎么能将其方法重构为更合适的对象类？
-
我有一个坚实的架构吗？ 也就是说，我是在使用抽象和inheritance而不是在每个class级重新发明轮子吗？ 重载方法是否适当调用基本方法？
-
我真的需要所有这些代码吗？ 是否可以使用xpath，lambda表达式或某种forms的数据库驱动表达式来外化某些逻辑？
-
代码是否可扩展？ 容易维护吗？ 它是从一开始就设计得很好，还是我们总是制作小补丁来试图解决问题？
我希望这有点帮助; 重构大型课程可能很困难，但我认为如果你开始查看我的问题，你可能会很快发现你的代码还有改进空间……我知道我通常会这样做。
特别是看＃1 – 人们在整个地方创建大量的帮助类是非常普遍的，这是非常反面向对象的（在我看来）。 这是一个不同的主题，但你可能想看看你所做的课程中真正的所谓 – 以及在其他地方可能/应该是什么。
根据经验，如果类是可维护且灵活的，则可能不需要更改。 🙂
在C＃中，我对类的经验法则是超过500行太长了。 我真的很喜欢10行以下的方法，我猜20岁以下是可以接受的。 我认为这取决于具体情况。
只要你有机会重构：
- 引入适当的设计模式代替意大利面条代码
- 降低代码复杂性并提高可读性
- 通过引入单个方法调用来删除冗余代码
- 从业务逻辑中解放出来的UI
等等
编辑：显然，重构的决定应考虑到时间，潜在的回报，其他责任等。
重构不是减少LOC的数量，尽管这是副作用，但提高了质量。 特别是，你想尽可能地尝试遵循DRY（不要重复自己）原则。
我倾向于查看每个成员的圈复杂度，而不是整个类的代码行数。
我的经验法则是方法，而不是类 – 如果我在屏幕上看不到整个方法，则需要重构。 当然， 传统的气味适用。
这个类可能是“提取一个你认为不存在的对象”的重构练习的候选者？
或许，例如，您可以提取一个方法对象，允许您将50行方法中的几个重构为提取类的成员？
或者，将一些包含业务逻辑的私有方法封装在与此协作的新对象中可能会提供一种重用此对象或提取的对象的新方法。
一行足以考虑重构。 40个每行50行的方法开始尖叫“我太复杂了，还有另一个藏在这里的物体”在我耳边。