Java杂谈之代码重构的方法多长才算长

目录
  • 多长算“长”?
  • 长函数的产生
  • 以性能为由
  • 平铺直叙
  • 一次加一点
  • 总结

每当看到长函数,我们都得:

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

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

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

多长算“长”?

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>

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

即便以 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
                }
            }
        }
    }

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

翻译引擎是另外一个服务,需通过 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);
    }
}

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

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

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

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

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

一次加一点

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

长函数产生的原因:

  • 性能为借口
  • 代码平铺直叙

函数写长最常见的原因。之所以会把代码平摊在那里:
- 把多个业务写到了一起
- 把不同层次的代码写到了一起。究其根因,那是“分离关注点”没有做好

  • 每人每次加一点点

应对主要办法就是要坚守“童子军军规”,但其背后更深层次的支撑就是要对坏味道有着深刻的认识

把函数写短,越短越好。

到此这篇关于Java杂谈之代码重构的方法多长才算长的文章就介绍到这了,更多相关Java 代码重构内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Java基础之多线程方法状态和创建方法

    目录 Java之线程的五大状态及其常用方法(六个状态还有timed_wating超时等待) 1.线程的五大状态及其转换 2.设置或获取多线程的线程名称的方法 3.线程休眠------sleep()方法 4.线程让步------yield()方法 5. 等待线程终止------join()方法 6. 线程停止 7. 线程等待------wait()方法 8. 线程唤醒-------notify()方法 9. notifyAll()方法 JAVA多线程有哪几种实现方式? 1. 继承Thread类 2

  • Java基础(第二篇)方法与数据成员

    目录 1.调用同一对象的数据成员 2.方法的参数列表 3.调用同一对象的其他方法 4.数据成员初始化 5.总结 上一篇文章Java基础 从HelloWorld到面向对象 1.调用同一对象的数据成员 方法可以调用该对象的数据成员.比如下面我们给Human类增加一个getHeight()的方法.该方法返回height数据成员的值: public class Test { public static void main(String[] args) { Human aPerson = new Huma

  • Java代码重构的几种模式详解

    Java代码的重构模式主要有三种: 重命名方法重构模式.引入解释性变量重构模式.以查询取代临时变量重构模式 重命名方法重构模式建议执行如下的步骤来完成: 1.建立一个具有新名称的方法 2.将旧方法的方法体复制进新方法 3.讲旧方法的方法体修改为调用新方法 4.将所有引用旧方法的地方修改为引用新方法 5.删除旧方法 引入解释性变量重构模式步骤相对简单,如下: 1.声明一个局部变量,并将其初始化为需要替换的表达式部分 2.对于复杂的表达式,用新的局部变量代替其中需要替换的部分 3.对于该表达式的其他

  • 详解如何把Java中if-else代码重构成高质量代码

    为什么我们写的代码都是if-else? 程序员想必都经历过这样的场景:刚开始自己写的代码很简洁,逻辑清晰,函数精简,没有一个if-else, 可随着代码逻辑不断完善和业务的瞬息万变:比如需要对入参进行类型和值进行判断:这里要判断下对象是否为null:不同类型执行不同的流程. 落地到具体实现只能不停地加if-else来处理,渐渐地,代码变得越来越庞大,函数越来越长,文件行数也迅速突破上千行,维护难度也越来越大,到后期基本达到一种难以维护的状态. 虽然我们都很不情愿写出满屏if-else的代码,可逻

  • Java杂谈之代码重构的方法多长才算长

    目录 多长算"长"? 长函数的产生 以性能为由 平铺直叙 一次加一点 总结 每当看到长函数,我们都得: 被迫理解一个长函数 在一个长函数中,小心翼翼地找出需要的逻辑,按需求微调 几乎所有程序员都会有类似经历. 没人喜欢长函数,但你却要一直和各种长函数打交道. 几百上千行的函数肯定是不足以称霸的. 多长算"长"? 100 行?对于函数长度容忍度太高了!这是导致长函数产生的关键点. 看具体代码时,一定要能够看到细微之处.关键点就是将任务拆解得越小越好,这个观点对代码同样

  • Java杂谈之重复代码是什么

    目录 方法为何要有参数? 长参数列表的问题 解决方案 聚沙成塔 动静分离 告别标记 总结 有经验的程序员应该都见过,一个方法坐拥几十上百个参数. 方法为何要有参数? 因为不同方法间需共享信息. 但方法间共享信息的方式不止一种,除了参数列表,还有全局变量.但全局变量总能带来意外惊喜,所以,取消全局变量也是各大语言的趋势. 但方法之间还是要传递信息的,不能用全局变量,于是参数就成了唯一选择,于是,只要你想到有什么信息要传给一个方法,就会直接它加到参数列表中,参数列表也越来越长. 长参数列表的问题 参

  • Java杂谈之如何消除代码中一大串参数列表

    目录 方法为何要有参数? 长参数列表的问题 解决方案 聚沙成塔 动静分离 告别标记 总结 有经验的程序员应该都见过,一个方法坐拥几十上百个参数. 方法为何要有参数? 因为不同方法间需共享信息. 但方法间共享信息的方式不止一种,除了参数列表,还有全局变量.但全局变量总能带来意外惊喜,所以,取消全局变量也是各大语言的趋势. 但方法之间还是要传递信息的,不能用全局变量,于是参数就成了唯一选择,于是,只要你想到有什么信息要传给一个方法,就会直接它加到参数列表中,参数列表也越来越长. 长参数列表的问题 参

  • java代码效率优化方法(推荐)

    1. 尽量指定类的final修饰符 带有final修饰符的类是不可派生的. 如果指定一个类为final,则该类所有的方法都是final.Java编译器会寻找机会内联(inline)所有的 final方法(这和具体的编译器实现有关).此举能够使性能平均提高50% . 2. 尽量重用对象. 特别是String 对象的使用中,出现字符串连接情况时应用StringBuffer 代替.由于系统不仅要花时间生成对象,以后可能还需花时间对这些对象进行垃圾回收和处理.因此,生成过多的对象将会给程序的性能带来很大

  • PHP代码重构方法漫谈

    本文实例分析了PHP代码重构方法.分享给大家供大家参考,具体如下: 随着 PHP 从一种简单的脚本语言转变为一种成熟的编程语言,一个典型的 PHP 应用程序的代码库的复杂性也随之增大.为了控制对这些应用程序的支持和维护,我们可以使用各种测试工具来自动化该流程.其中一种是单元测试,它允许您直接测试所编写代码的正确性.然而,通常遗留代码库是不适合进行这种测试的.本文将介绍对包含常见问题的 PHP 代码的重构策略,以便简化使用流行的单元测试工具进行测试的过程,同时减少改进代码库的依赖性. 简介 回顾

  • Java杂谈之类和对象 封装 构造方法以及代码块详解

    目录 1. 类和对象的初步认知 2. 类的实例化 3. 类的成员 字段(属性/成员变量) 方法 static 关键字 修饰字段 修饰方法 修饰代码块(暂不讲) 修饰类(暂不讲) 4. 封装 5. 构造方法 6. this 用法 关于引用的几个注意事项: 7. 代码块 Java当中的类和对象 1. 类和对象的初步认知 java 是一门面向对象的语言,所谓面向对象有别于面向过程,面向对象是只需对象之间的交互即可完成任务,但是面向过程的话,需要我们将每一个步骤都详细地做出来.比如,以洗衣服为例,如果是

  • Java杂谈之如何优化写出漂亮高效的代码

    目录 命名中的不一致 方案中的不一致 代码中的不一致 总结 大部分程序员对于一致性本身的重要性是有认知的.但通常来说,大家理解的一致性都表现在比较大的方面,比如,数据库访问是叫 DAO还是叫 Mapper,Repository?在一个团队内,这是有统一标准的,但编码的层面上,要求往往就不是那么细致了.所以,我们才会看到在代码细节上呈现出了各种不一致.我们还是从一段具体的代码来分析问题. 命名中的不一致 有一次,我在代码评审中看到了这样一段代码: enum DistributionChannel

  • Java线程代码的实现方法

    一.线程Java代码实现 1.继承Thread 声明Thread的子类 public class MyThread extends Thread { public void run(){ System.out.println("MyThread running"); } } 运行thread子类的方法 MyThread myThread = new MyThread(); myTread.start(); 2.创建Thread的匿名子类 Thread thread = new Thre

  • Java计算程序代码执行时间的方法小结

    本文实例总结了Java计算程序代码执行时间的方法.分享给大家供大家参考,具体如下: 有时候为了排查性能问题,需要记录完成某个操作需要的时间,我们可以使用System类的currentTimeMillis()方法来返回当前的毫秒数,并保存到一个变量中,在方法执行完毕后再次调用 System的currentTimeMillis()方法,并计算两次调用之间的差值,就是方法执行所消耗的毫秒数. 如方法一: long startTime = System.currentTimeMillis(); //获取

随机推荐