每当看到长函数，我们都得：

• 被迫理解一个长函数
• 在一个长函数中，小心翼翼地找出需要的逻辑，按需求微调

几乎所有程序员都会有类似经历。
没人喜欢长函数，但你却要一直和各种长函数打交道。

几百上千行的函数肯定是不足以称霸的。

多长算“长”？

100 行？对于函数长度容忍度太高了！这是导致长函数产生的关键点。

看具体代码时，一定要能够看到细微之处。关键点就是将任务拆解得越小越好，这个观点对代码同样适用。随着对代码长度容忍度的降低，对代码细节的感知力就会逐渐提升，你才能看到那些原本所谓细枝末节的地方隐藏的各种问题。

“越小越好”是一个追求的目标，不过，没有一个具体的数字，就没办法约束所有人的行为。所以，通常情况下，我们还是要定义出一个代码行数的上限，以保证所有人都可以按照这个标准执行。

像 Java 这样表达能力稍弱的静态类型语言，争取 20 行代码解决问题。

这不是一个说说就算的标准，我们应该把它变成一个可执行的标准。比如，在 Java 中，我们就可以把代码行的约束加到 CheckStyle 的配置文件：

<module name="MethodLength">
    <property name="tokens" value="METHOD_DEF"/>
    <property name="max" value="20"/>
    <property name="countEmpty" value="false"/>
</module>

  

 

  
1
  
2
  
3
  
4
  
5
 

这样，在我们提交代码之前，执行本地的构建脚本，就可以把长函数检测出来。

即便以 20 行上限，这也已经超过很多人的认知，具体的函数行数可以结合团队的实际情况来制定。
非常不建议把这个数字放得很大，就像我前面说的那样，如果你放到 100 行，这个数字基本上是没有太多意义的，对团队也起不到什么约束作用。

• 如果函数里面的行写得很长呢？还应不应该插入换行？如果插入换行的话就会增加行数，如果不差入换行，在看代码时就要经常移动水平滚动条
  按代码行而非物理行计数。

长函数的产生

限制函数长度，是一种简单粗暴的解决方案。最重要的是你要知道，长函数本身是一个结果，如果不理解长函数产生的原因，还是很难写出整洁的代码。

以性能为由

像 C 语言这种在今天已经是高性能的程序设计语言，在问世之初，也曾被人质疑性能不彰，尤其是函数调用。

在一些写汇编语言的人看来，调用函数涉及到入栈出栈的过程，显然不如直接执行来得性能高。这种想法经过各种演变流传到今天，任何一门新语言出现，还是会以同样的理由被质疑。

所以，在很多人看来，把函数写长是为了所谓性能。不过，这个观点在今天是站不住的。性能优化不该是写代码的第一考量:

• 有活力的程序设计语言本身是不断优化的，无论是编译器，还是运行时，性能都会越来越好
• 可维护性比性能优化要优先考虑，当性能不足以满足需要时，我们再来做相应的测量，找到焦点，进行特定的优化。这比在写代码时就考虑所谓性能要更能锁定焦点，优化才有意义。

平铺直叙

写代码平铺直叙，把自己想到的一点点罗列出来。比如下面这段代码（如果你不想仔细阅读，可以直接跳到后面）：

public void executeTask() {
    ObjectMapper mapper = new ObjectMapper();
    CloseableHttpClient client = HttpClients.createDefault();
    List<Chapter> chapters = this.chapterService.getUntranslatedChapters();
    for (Chapter chapter : chapters) {
        // Send Chapter
        SendChapterRequest sendChapterRequest = new SendChapterRequest();
        sendChapterRequest.setTitle(chapter.getTitle());
        sendChapterRequest.setContent(chapter.getContent());


        HttpPost sendChapterPost = new HttpPost(sendChapterUrl);
        CloseableHttpResponse sendChapterHttpResponse = null;
        String chapterId = null;
        try {
            String sendChapterRequestText = mapper.writeValueAsString(sendChapterRequest);
            sendChapterPost.setEntity(new StringEntity(sendChapterRequestText));
            sendChapterHttpResponse = client.execute(sendChapterPost);
            HttpEntity sendChapterEntity = sendChapterPost.getEntity();
            SendChapterResponse sendChapterResponse = mapper.readValue(sendChapterEntity.getContent(), SendChapterResponse.class);
            chapterId = sendChapterResponse.getChapterId();
        } catch (IOException e) {
            throw new RuntimeException(e);
        } finally {
            try {
                if (sendChapterHttpResponse != null) {
                    sendChapterHttpResponse.close();
                }
            } catch (IOException e) {
                // ignore
            }
        }


        // Translate Chapter
        HttpPost translateChapterPost = new HttpPost(translateChapterUrl);
        CloseableHttpResponse translateChapterHttpResponse = null;
        try {
            TranslateChapterRequest translateChapterRequest = new TranslateChapterRequest();
            translateChapterRequest.setChapterId(chapterId);
            String translateChapterRequestText = mapper.writeValueAsString(translateChapterRequest);
            translateChapterPost.setEntity(new StringEntity(translateChapterRequestText));
            translateChapterHttpResponse = client.execute(translateChapterPost);
            HttpEntity translateChapterEntity = translateChapterHttpResponse.getEntity();
            TranslateChapterResponse translateChapterResponse = mapper.readValue(translateChapterEntity.getContent(), TranslateChapterResponse.class);
            if (!translateChapterResponse.isSuccess()) {
                logger.warn("Fail to start translate: {}", chapterId);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        } finally {
            if (translateChapterHttpResponse != null) {
                try {
                    translateChapterHttpResponse.close();
                } catch (IOException e) {
                    // ignore
                }
            }
        }
    }

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
  
36
  
37
  
38
  
39
  
40
  
41
  
42
  
43
  
44
  
45
  
46
  
47
  
48
  
49
  
50
  
51
  
52
  
53
  
54
  
55
  
56
  
57
  
58
  
59
  
60
 

把没有翻译过的章节发到翻译引擎，然后，启动翻译过程。

翻译引擎是另外一个服务，需通过 HTTP 的形式向它发送请求。相对而言，这段代码还算直白，当你知道了我上面所说的逻辑，你是很容易看懂这段代码。

这段代码之所以很长，主要原因就是把前面所说的逻辑全部平铺直叙地摆在那里了，这里既有业务处理的逻辑，比如，把章节发送给翻译引擎，然后，启动翻译过程；又有处理的细节，比如，把对象转成 JSON，然后，通过 HTTP 客户端发送出去。

从这段代码中，可看到平铺直叙的代码存在的两个典型问题：

• 把多个业务处理流程放在一个函数里实现
• 把不同层面的细节放到一个函数里实现

这里发送章节和启动翻译是两个过程，显然，这是可以放到两个不同的函数中去实现的，所以，我们只要做一下提取函数，就可以把这个看似庞大的函数拆开，而拆出来的几个函数规模都会小很多，像下面这样：

public void executeTask() {
    ObjectMapper mapper = new ObjectMapper();
    CloseableHttpClient client = HttpClients.createDefault();
    List<Chapter> chapters = this.chapterService.getUntranslatedChapters();
    for (Chapter chapter : chapters) {
        String chapterId = sendChapter(mapper, client, chapter);
        translateChapter(mapper, client, chapterId);
    }
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
 

拆出来的部分，实际上就是把对象打包发送的过程，我们以发送章节为例，先来看拆出来的发送章节部分：

private String sendChapter(final ObjectMapper mapper,
                           final CloseableHttpClient client,
                           final Chapter chapter) {
    SendChapterRequest request = asSendChapterRequest(chapter);


    CloseableHttpResponse response = null;
    String chapterId = null;
    try {
        HttpPost post = sendChapterRequest(mapper, request);
        response = client.execute(post);
        chapterId = asChapterId(mapper, post);
    } catch (IOException e) {
        throw new RuntimeException(e);
    } finally {
        try {
            if (response != null) {
                response.close();
            }
        } catch (IOException e) {
            // ignore
        }
    }
    return chapterId;
}


private HttpPost sendChapterRequest(final ObjectMapper mapper, final SendChapterRequest sendChapterRequest) throws JsonProcessingException, UnsupportedEncodingException {
    HttpPost post = new HttpPost(sendChapterUrl);
    String requestText = mapper.writeValueAsString(sendChapterRequest);
    post.setEntity(new StringEntity(requestText));
    return post;
}


private String asChapterId(final ObjectMapper mapper, final HttpPost sendChapterPost) throws IOException {
    String chapterId;
    HttpEntity entity = sendChapterPost.getEntity();
    SendChapterResponse response = mapper.readValue(entity.getContent(), SendChapterResponse.class);
    chapterId = response.getChapterId();
    return chapterId;
}


private SendChapterRequest asSendChapterRequest(final Chapter chapter) {
    SendChapterRequest request = new SendChapterRequest();
    request.setTitle(chapter.getTitle());
    request.setContent(chapter.getContent());
    return request

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
  
36
  
37
  
38
  
39
  
40
  
41
  
42
  
43
  
44
  
45
  
46
  
47
  
48
  
49
 

这个代码还算不上已经处理得很整洁了，但至少同之前相比，已经简洁了一些。我们只用了最简单的提取函数这个重构手法，就把一个大函数拆分成了若干的小函数。

长函数往往还隐含着一个命名问题。如果你看修改后的sendChapter，其中的变量命名明显比之前要短，理解的成本也相应地会降低。因为变量都是在这个短小的上下文里，也就不会产生那么多的命名冲突，变量名当然就可以写短一些。

平铺直叙的代码，一个关键点就是没有把不同的东西分解出来。如果我们用设计的眼光衡量这段代码，这就是“分离关注点”没有做好，把不同层面的东西混在了一起，既有不同业务混在一起，也有不同层次的处理混在了一起。我在《软件设计之美》专栏中，也曾说过，关注点越多越好，粒度越小越好。

一次加一点

有时，一段代码一开始的时候并不长，就像下面这段代码，它根据返回的错误进行相应地错误处理：

if (code == 400 || code == 401) {
  // 做一些错误处理
}

  

 

  
1
  
2
  
3
 

然后，新的需求来了，增加了新的错误码，它就变成了这个样子：

if (code == 400 || code == 401 || code == 402) {
  // 做一些错误处理
}

  

 

  
1
  
2
  
3
 

这段代码有很多次被修改的机会，日积月累：

if (code == 400 || code == 401 || code == 402 || ...
  || code == 500 || ...
  || ...
  || code == 10000 || ...) {
}

  

 

  
1
  
2
  
3
  
4
  
5
 

后人看到就想骂人。任何代码都经不起这种无意识的累积，每个人都没做错，但最终的结果很糟糕。对抗这种逐渐糟糕腐坏的代码，需要知道“童子军军规”：
让营地比你来时更干净。

Robert Martin 把它借鉴到了编程领域，我们应该看看自己对于代码的改动是不是让原有的代码变得更糟糕了，如果是，那就改进它。
但这一切的前提是，你要能看出自己的代码是不是让原有的代码变得糟糕了，所以，学习代码的坏味道还是很有必要的。

至此，我们看到了代码变长的几种常见原因：

• 以性能为由
• 平铺直叙
• 一次加一点

代码变长根本是一个无意识的问题，写代码的人没有觉得自己把代码破坏了。但只要你认识到长函数是一个坏味道，后面的许多问题就自然而然地会被发掘出来，至于解决方案，你已经看到了，大部分情况下，就是拆分成各种小函数。

总结

没有人愿意去阅读长函数，但许多人又会不经意间写出长函数。

对于团队，一个关键点是要定义出长函数的标准。
过于宽泛的标准没有意义，想要有效地控制函数规模，几十行已经是标准上限，这个标准越低越好。

长函数产生的原因：

• 性能为借口
• 代码平铺直叙
  函数写长最常见的原因。之所以会把代码平摊在那里：
  - 把多个业务写到了一起
  - 把不同层次的代码写到了一起。究其根因，那是“分离关注点”没有做好
• 每人每次加一点点
  应对主要办法就是要坚守“童子军军规”，但其背后更深层次的支撑就是要对坏味道有着深刻的认识

把函数写短，越短越好。

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/120438225