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