可以将长函数和方法拆分为较小的函数，即使它们不会被其他任何东西调用也可以吗？ [重复]

#1 楼

测试执行很多任务的代码很困难。

调试执行很多任务的代码很困难。

解决这两个问题的方法是编写不执行任何操作的代码。做很多事情。编写每个函数，使其仅执行一项操作。这使他们易于使用单元测试进行测试（一个人不需要进行十几个单元测试）。

我的一位同事在判断给定方法是否需要时使用了他的短语。分解成较小的部分：


如果在向另一位程序员描述代码的活动时使用“和”一词，则该方法至少需要分成另外一部分。


您写道：


我有一个process_url（）函数，该函数将URL拆分为组件，然后通过其方法将其分配给某些对象。


这应该至少是两种方法。可以将它们包装成一种面向公众的方法，但是工作方式应该是两种不同的方法。

#2 楼

是的，拆分长函数是正常的。罗伯特·C·马丁（Robert C. Martin）在他的《清洁代码》一书中鼓励这种做法。特别是，您应该为函数选择非常具有描述性的名称，作为一种自我记录代码的形式。

#3 楼

正如人们指出的那样，这提高了可读性。仅仅阅读一些方法名称，阅读process_url()的人可能会更清楚地看到处理URL的一般过程。

问题是，其他人可能会认为这些功能已被其他方法使用。代码，如果其中一些需要更改，他们可以选择保留这些功能并定义新功能。这意味着某些代码变得无法访问。

有几种方法可以解决此问题。首先是代码中的文档和注释。第二，提供覆盖率测试的工具。无论如何，在很大程度上取决于编程语言，以下是您可以根据编程语言应用的一些解决方案：


面向对象的语言可以允许定义一些私有方法，以确保不在其他地方使用它们。
其他语言的模块可以指定从外部可见的函数，等等。
像Python这样的高级语言可能不需要定义多个函数，因为它们无论如何都会很简单
其他语言（例如Prolog）可能需要（或强烈建议）为每个条件跳转定义一个新的谓词。
在某些情况下，通常会在使用该函数的函数中定义辅助函数它们（本地函数），有时是匿名函数（代码闭包），这在Javascript回调函数中很常见。

因此，简而言之，就可读性而言，拆分多个函数通常是一个好主意。如果函数很短并且会产生goto效果，或者名称不是真正的描述性，那可能不是很好，在这种情况下，读取某些代码将需要在函数之间跳转，这可能很麻烦。关于您对这些功能的范围和用法的关注，有几种处理方式，这些方式通常取决于语言。

通常，最好的建议是使用常识。任何严格的规则在某些情况下很可能是错误的，最终取决于人。我认为这是可读的：

 process_url = lambda url: dict(re.findall('([^?=&]*)=([^?=&]*)', url))
 

我个人更喜欢一种衬板，即使它是稍微复杂一点，而不是跳过并搜索多个代码文件，如果我花了三秒钟多的时间才能找到代码的其他部分，我什至不知道我在检查什么。没有遭受多动症困扰的人们可能会喜欢他们会记住的更多解释性名称，但是最后，您总是要做的是平衡代码，行，段落，函数，文件，模块等不同级别上的复杂性。

所以关键字是balance。拥有一千行的函数对于任何阅读它的人来说都是一个地狱，因为它没有封装并且上下文变得太大。将一个函数拆分为一千个函数，每个函数中只有一行的情况可能会更糟：


您有一些名称（可以在行中作为注释提供）
（希望）消除全局变量，而不必担心状态（具有参照透明性）
，但是您迫使读者来回跳动。

所以没有这里有银弹，但经验和平衡。恕我直言，学习如何执行此操作的最佳方法是阅读许多其他人编写的代码，并分析为什么您很难阅读它以及如何使其更具可读性。这将提供宝贵的经验。

#4 楼

我会说这要视情况而定。

如果只是为了拆分而将其拆分，并称其名称为process_url_partN等，则否，请不要。如果您或其他人需要弄清楚正在发生的事情，这只会使以后很难遵循。

如果您要推出具有明确目的的方法，这些方法可以自己进行测试并且很有意义他们自己的（即使没有其他人在使用它们）则为是。


出于您的特定目的，看来您有两个目标。


解析一个URL并返回其组件列表。
对那些组件进行一些操作。

我将第一部分单独编写，让它返回一个相当通用的结果，可以轻松地对其进行测试并可能在以后重用。更好的是，我会寻找一个内置函数，该函数已经在您的语言/框架中执行了此操作，并使用了该函数，除非您的解析非常特殊。如果它非常特殊，我仍将其编写为单独的方法，但可能会将其“捆绑”为处理第二个类的类中的私有/受保护的方法（如果您正在编写面向对象的代码）。

第二部分我将作为自己的组件编写，它使用第一部分进行URL解析。

#5 楼

我从未遇到过其他开发人员将较大的方法拆分为较小的方法的问题，因为这是我自己遵循的模式。 “上帝”方法是一个可怕的陷阱，其他经验不足或根本不在乎的人往往会被更多地抓住。话虽这么说...

在较小的方法上使用适当的访问标识符非常重要。找到一个乱七八糟的类，这很令人沮丧，因为那样一来，我就完全找不到对整个应用程序使用该方法的位置/方式的信心。

我住在C＃-land上，所以我们有public，private， protected，internal，看到这些单词使我毫无疑问地看到了方法的范围以及必须在哪里寻找调用的地方。如果它是私有的，那么我知道该方法仅在一个类中使用，并且在重构时我完全有信心。

在Visual Studio世界中，拥有多个解决方案（.sln）会加剧此反模式，因为IDE /重新共享“查找用法”助手将不会在开放式解决方案之外找到用法。

#6 楼

如果您的编程语言支持它，则可以在process_url()函数的范围内定义“辅助”函数，以获得单独函数的可读性。例如，

function process_url(url) {

    function foo(a) {
        // ...
    }

    function bar(a) {
        // ...
    }

    return [ foo(url), bar(url) ];

}

如果您的编程语言不支持此功能，则可以将foo()和bar()移出process_url()的范围（以便其他功能/方法）-但您认为这是您的“ hack”，因为您的编程语言不支持此功能。

是否将功能分解为子功能可能取决于是否除其他考虑因素外，还有有意义的/有用的名称，以及各个功能的大小。

#7 楼

如果有人对这个问题感兴趣，那么这就是约书亚·克列耶夫斯基（Joshua Kerievsky）在他的“模式重构”（Addison-Wesley）中所说的“合成方法”：


转换将逻辑分解成少量细节相同的意图揭示步骤。


我相信，根据方法的“详细程度”正确嵌套方法在这里很重要。 />
在发布者的网站上查看摘录：


我们编写的许多代码并非一开始就很简单。为简单起见，我们必须反思一下不简单的地方，然后不断问：“它怎么会更简单？”我们通常可以通过考虑完全不同的解决方案来简化代码。本章中的重构为简化方法，状态转换和树结构提供了不同的解决方案。

编写方法（123）涉及产生能够有效传达其工作方式和工作方式的方法。组合方法[Beck，SBPP]包含对详细名称相同的命名方法的调用。如果要使系统保持简单，请尝试在任何地方应用Compose Method（123）...




附录：Kent Beck（“实现模式” ”）称为“组合方法”。他建议您：


[c]在对其他方法的调用之外合并方法，每个方法大致处于相同的抽象级别。
组成不佳的方法的迹象中有很多是抽象层次的混合。




再次警告不要混合不同的抽象层次（强调我的）。

#8 楼

一个好的规则是在相似的级别上具有附近的抽象（由塞巴斯蒂安更好地在上面的答案中提出）。

如果您有一个处理低级内容的（大型）函数，但也做了一些较高级别的选择，请尝试排除低级内容：

void foo() {

     if(x) {
       y = doXformanysmallthings();
     }

     z = doYforthings(y);

     if (z != y && isFullmoon()) {
         launchSpacerocket()
     }
}

将内容移到较小的函数通常比在其中包含一些概念上的“大”步骤的函数中包含许多循环更好。 （除非您可以将其组合成相对较小的LINQ / foreach / lambda表达式...）

#9 楼

如果您可以设计适合这些功能的类，请将它们设为私有。换句话说，使用合适的类定义，您可以只公开需要公开的内容。

#10 楼

我敢肯定这不会成为流行观点，但这是完全可以的。引用的局部性可以极大地帮助您确保您和其他人理解该功能（在这种情况下，我指的是代码，而不是专门针对内存）。

与所有内容一样，这是一种平衡。您应该更关心那些告诉您“总是”或“从不”的人。

#11 楼

考虑这个简单的功能（我使用的是类似Scala的语法，但我希望这个想法在没有任何Scala知识的情况下就能弄清楚）：

def myFun ... {
    ...
    if (condition1) {
        ...
    } else {
        ...
    }
    if (condition2) {
        ...
    } else {
        ...
    }
    if (condition3) {
        ...
    } else {
        ...
    }
    // rest
    ...
}

此函数具有多达8条可能的路径，取决于这些条件的评估方式，这些代码可以如何执行。


这意味着您将需要8个不同的测试才能测试这部分。此外，很可能某些组合是不可能的，然后您必须仔细分析它们是什么（并确保不要错过某些可能的组合）-很多工作。
很难有关代码及其正确性的原因。由于每个if块及其条件都可能取决于某些共享的局部变量，为了知道它们之后发生的情况，使用该代码的每个人都必须分析所有这些代码块和8个可能的执行路径。在这里容易犯错误，很可能有人更新代码会丢失某些东西并引入错误。

另一方面，如果将计算结构化为

def myFun ... {
    ...
    val result1 = myHelper1(...);
    val result2 = myHelper2(...);
    val result3 = myHelper3(...);
    // rest
    ...
}

private def myHelper1(/* arguments */): SomeResult = {
    if (condition1) {
        ...
    } else {
        ...
    }
}
// Similarly myHelper2 and myHelper3

您可以：


容易地测试每个助手功能，每个助手功能只有两个可能的执行路径。
检查myFun时如果result2依赖于result1，则立即显而易见（只需检查对myHelper2(...)的调用是否使用它来计算参数之一。（假设帮助程序不使用某些全局状态。）很明显，它们是如何依赖的，此外，在这三个调用之后，还很清楚计算状态如何-只需在result1，result2和result3中捕获-无需检查是否/是否需要其他局部变量已被修改。

#12 楼

方法具有更具体的责任，代码将更易于测试，读取和维护。尽管没有其他人打电话给他们。

如果将来需要在其他地方使用此功能，则可以轻松提取这些方法。

#13 楼

像这样命名您的方法是完全可以接受的：

MyProcedure()
  MyProcedure_part1()
  MyProcedure_part2()
end;

我不明白为什么有人会认为这些方法会被其他进程调用，这是完全清楚它们的用途。