写点什么

不要让“Clean Code”更难维护,请使用“Rule of Three”

2020 年 4 月 20 日

不要让“Clean Code”更难维护,请使用“Rule of Three”

“我们如何证明,通过遵循“代码整洁之道”(Clean Code)就可以编写更多的代码呢?”


当人们试图将“代码整洁之道(Clean Code)”的原则应用于现有的代码库时,我经常会问这个问题。


我认为这是合情合理的。


当我们开始重构遗留代码时,通常会将内容提取到较小的方法中。然后再将方法提取到类中。很快,我们可能就能感觉到原来 30 行的方法现在已经分散在不同的类中。


我们想知道的是:这在实际上是否是更容易维护了呢。


也许我们是一个小团队。也许我们必须支持我们继承的一个相对较大(并且没有文档记录的)的代码库。


寻求代码可维护性是一件好事。


错误在于,认为代码可维护性与代码行数(lines of code,LOC)相关。LOC 可能是一个有趣的度量指标,但它并不是关键所在!


不要使用 LOC 作为代码可维护性的度量指标。


简短的代码并没有更好的可读性。


如果你对此有所怀疑,那么应该看看“短码之美(Code Golf)”。


当我们进行“短码竞赛”时,我们的目标是找到一些聪明的技巧,用最少的代码字符来实现相同的功能:


// 31 个字符  Math.floor(Math.random() * 100)
// 21 个字符 ~~(Math.random()*100)
// 19 个字符 Math.random()*100|0
复制代码


但当然,这只是一个“strawman”的论点!


我相信我们不会以“短码竞赛”的方式来编写生产中的代码。


然而,有一个重要的原则,我们需要记住:


代码不是我们告诉计算机怎么做的方式;而是告诉另一个程序员我们想要计算机做什么的方式。


简而言之:编写代码是要供他人阅读的


易于理解的代码才是易于维护的代码。


还是,难道我们还不够聪明,而无法阅读冗长的函数吗?出于可读性的考虑,添加一堆一次性使用的助手函数又有什么好处呢?


如果这些问题能引起我们的共鸣,那么我们需要知道一个秘密……


过早的重构是项目失败的根源


任何极端的做法都是有害的。


即使是遵循“代码整洁之道”的原则。


我们正在尝试一些事情。当然,我们可以按照最佳实践来重构代码,但这同时也会增加了维护的难度。如果我们为了达到此目的而只是封装了一个条件语句,那么它可能没有帮助!


不,我们不应该为了可读性,而将所有内容都提取到“一次性助手函数”中。如果我们每次阅读代码时都需要阅读这些函数的主体,那么这一点也没有帮助。它只会是阻碍。


我们应该做的是,创建正确的抽象。


正确的抽象,正确地划分职责。它们阐明了代码的意图。它们可以防止代码重复。


当我们找到正确的抽象时,我们会觉得这 4 个类实际上比原来的 30 行代码更易于维护。


但是,要找到正确的抽象确实很困难。因此,这就是我们应该关注的重点。


坏的抽象比重复更糟糕


你是否听说过“不要重复你自己(Don’t Repeat Yourself,DRY)”原则?


这是一颗共同发展智慧的明珠,而且非常有效。但它也经常被误解。


两段代码看起来是一样的,但却代表了不同的概念。不同的抽象。在这种情况下,重复是偶然的。保留重复会更好。


“重复与错误的抽象相比,代价要小的多”

—— Sandi Metz, 所有的小事


什么时候应该将代码提取到函数/方法/类中?什么时候应该保留重复?我们怎么知道我们有正确的抽象呢?


使用“Rule of Three”


Also called Write Everything Twice (WET). Pun intended.


这也称为“什么都写两遍(Everything Twice,WET)”。这是个双关语(与 DRY 原则相对)。


“三次重复攻击,就重构”


重构原则“Rule of Three”是一条经验规则,当我们有疑问时可以使用它。


在引入抽象之前,请等待第三次重复的出现。出现重复的次数越多,就越容易找到要提取的共性。


遵循“Rule of Three”原则。它能使我们更容易地找到正确的抽象。


超越“Rule of Three”


这里的“Rule of Three”原则是为了提醒我们,重复是可以的。


这也有点教条。就像“代码整洁之道”的原则一样,不要在任何时候都盲目地 100%应用它。


有时,即使出现了 3 次重复,我们也可能找不到正确的抽象。不要强求对代码库进行过度的抽象。如果我们不能给它起一个清晰的名字,它就确实不够清晰。


毫无疑问,违反规则是可以的。等待更多的重复。


宁可重复,也不要错误的抽象。不要为了抽象而创建抽象。


如果抽象不好,则必须使用布尔型的参数和 if 语句来简化它的实现,以覆盖新的用例。这只是一种暗示、一种警告,告诉你你走错了方向。


如果我们还没有找到抽象的话,那也没关系。当我们有了更多的上下文时,仍可以重构它。等着瞧吧!


原文链接:


https://understandlegacycode.com/blog/refactoring-rule-of-three/


2020 年 4 月 20 日 09:001408

评论 1 条评论

发布
用户头像
这篇文章总结一句话就是:事不过三,三则重构
2020 年 04 月 20 日 12:25
回复
没有更多了
发现更多内容

Apache Doris在京东广告的应用实践

DorisDB

数据库 大数据 数据仓库

Javassist实现JDK动态代理

AI乔治

Java 编程 架构 jdk

京东推荐系统中的兴趣拓展如何驱动业务持续增长?

京东智联云开发者

算法 推荐系统 知识图谱

架构师训练营 -week06-作业

大刘

极客大学架构师训练营

Java-技术专题-Object克隆方法解析

李浩宇/Alex

对抗验证概述

计算机与AI

学习 数据验证

【得物技术】一文读懂Vue生命周期

得物技术

Vue 生命周期 得物技术部 得物 钩子函数

JVM 源码解读之 CMS GC 触发条件

AI乔治

Java 架构 JVM GC

GitHub上最励志的计算机自学教程(重制版),前端小白到亚马逊工程师

沉默王二

GitHub 学习 程序员 面试

JavaScript 对象 — 重学 JavaScript

三钻

Java 前端 对象

TronChain波场链合约系统开发技术

薇電13242772558

区块链 智能合约

第二周总结

小兵

Java-技术专题-volatile关键字

李浩宇/Alex

程序员什么时候就该辞职了?

Java架构师迁哥

从实际案例聊聊Java应用的GC优化

AI乔治

Java 编程 架构 JVM GC

手撕面试题:多个线程顺序执行问题

海星

Java 面试 多线程

英特尔第十一代处理器 (代号Rocket Lake-S) 架构详情

intel001

LeetCode题解:78. 子集,递归+for循环+回溯,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

区块链钱包开发app,去中心多币种钱包搭建

WX13823153201

区块链钱包开发

直播带货需要运营者实名验证:规范行业有利于健康发展

石头IT视角

架构师训练营第六周作业

Shunyi

极客大学架构师训练营

Week 6 命题作业

阿泰

K近邻算法:机器学习萌新必学算法

华为云开发者社区

学习 算法

创新方案百花齐放,英特尔助力2020 EdgeX中国挑战赛推动智能边缘行业创新及人才发展

intel001

使用 Maven Archetype 基于 IDEA 快速创建项目

程序员小航

Java maven 开发 项目 Archetype

第二周作业

小兵

Redis可以做哪些事?

Java旅途

redis

用上ConcurrentHashMap,就没有并发问题了?

海拉鲁

Java 并发

蚂蚁金服首发887页Java面试宝典!还原真实面试情景+面试题

Java架构追梦

Java 编程 架构 面试 蚂蚁金服

架构师训练营 - 第 6、7、8、9、10 、11、12、13周学习总结(1 期)

阿甘

Java-技术专题-LocalDate和LocalTime和LocalDateTime

李浩宇/Alex

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

不要让“Clean Code”更难维护,请使用“Rule of Three”-InfoQ