据我所知，包含长序列操作的方法被认为是一件坏事，需要重新设计。更重要的是，我听说这个方法不应该比屏幕大（即所有方法代码都应该在IDE屏幕上一次显示，而不需要滚动）。
对此有什么一般规定吗？例如，“如果方法长度超过15行，则应该重构”？如果是这样，你如何重构它？只需使用提取方法吗？
答案 0 :(得分：5)
这取决于你问的是谁。 Robert Martin会告诉您有两条规则：
不要在线数方面考虑它。行数是一个随意且不重要的指标。根据逻辑上做的方法来考虑它。最好的规则是：
或者，更好的方式：
（仍然在这里引导鲍勃叔叔，我最近一直在努力打击清洁代码。）
将此与其他逻辑规则相结合，例如：
而且，一般，你最终会得到非常小的方法。但是，是的例外情况。在许多情况下，“一件事”用一行代码表示，可能是两行或三行。但它是简单而富有表现力的代码，很清楚“一件事”是什么。 （当然，方法的名称应该清楚地反映出这一点。）
然而，有时候，“一件事”是一系列较长的步骤。也许您有一个方法在您的域中封装单个原子进程，但该进程恰好由十几个或更多步骤组成。每一步都是它自己的“一件事”，它可能在其他方法内部还有其他“一件事”等等。
每种方法都做“一件事”。但是将更小的步骤聚合成更大的原子过程的更高级别的封装方法会更长一些，因为它们的“一件事”由许多较小的“一件事”组成。这很罕见，但它确实发生了。当它发生时通常的结果是一种方法，它只不过是一系列方法调用。 （这并不是说这是长方法的借口。仔细检查代码的逻辑，以确定重新分解更大的方法是否真的有意义。）
这种更大的封装方法通常是将Transaction Script Pattern应用于业务逻辑的结果。只需一步即可响应单个请求，该请求由业务逻辑中的多步骤流程组成。
方法应该小。他们应该甚至更小。如果不是，请仔细检查以确定原因。如果有多个级别的缩进，那通常表明它应该重新考虑。如果输入有多个检查和平衡，它可能会使用一些重新分解。如果该方法不止一件事或者有多个理由需要更改，那么肯定会重新计算。
答案 1 :(得分：0)
将较大的功能拆分为较小的功能通常是个好主意 如果它们设计得很好并且很容易理解发生了什么，这不是问题。但功能越大，这样做就越难。保持功能简单将使您以后更容易跟踪问题。
答案 2 :(得分：0)
早期的程序员过去常常将方法长度限制为10行代码。如果他们的方法更长，那么他们就分开了。这是一种过时的编程风格，不再广泛使用。大多数专家都认为方法只要对它们有意义就可以了。 （据此，这意味着只要没有逻辑上的突破点就不应该分解它们）
就个人而言，我会争取更短的方法。但话虽如此，除非有明显的逻辑突破点，否则我不强调分手。唯一的原因是它只是使我的代码更容易阅读和调试;特别是如果方法名称是描述性的。