程序员重构入门指南

文章首发于公众号「架构师指南」及个人博客 shuyi.tech,欢迎关注访问。

文章首发于公众号「架构师指南」及个人博客 shuyi.tech,欢迎关注访问。

对于刚入门的编程者来说,《重构》是一本不错的读物。它能给你带来一些重构思想上的改变,告诉你为什么要重构,应该怎么做重构。本文基于《重构》一书,整理重构所需的「思想」与「技巧」上的准备。

思想篇指的是对于重构的认识,理解这些思想能够让你更好地做好重构。而技巧篇指的是具体重构时的一些技巧,能够让你知道怎么写出更好的代码。

思想篇

重构之前先建立测试用例

重构的第一步,是为即将修改的代码建立一组可靠的测试用例。预见建立好的测试用例,是你的安全绳,它能告诉你工作是否完成了,是否存在可能的缺陷。

重构的价值

重构可以改进软件的设计。就像在不断整理代码一样,经常性的重构可以帮助代码维持自己该有的形态。重构使得软件更容易理解,不要让几个月之后其他人(甚至自己)也读不懂你的代码,清晰易懂的代码能让你更快理解代码的意图。重构能帮助找到bug,因为重构是小步快跑的,每一步都有一个猎手(测试用例)帮你抓到猎物(bug)。

好的重构,最终能帮你提高编程速度,提高编程带来的愉悦感。

文章首发于公众号「架构师指南」及个人博客 shuyi.tech,欢迎关注访问。

什么时候重构?

什么时候重构?第一次只管去做,第二次会反感,第三次应该重构。事不过三,三则重构。

专门拨出时间重构是不可能的,我们需要在日常工作中不断地重构。但是还没开始有重复的功能,就想着重构,那太可笑了。但是重复的代码或者代码有问题,超过三次之后还不动手,那么就有点偷懒了。

什么时候不重构?

当现有代码根本不能正常运作的时候,你应该重写,而不是重构。

重构应该是一个习惯

重构应该是一种工作习惯,在日常工作中一点点重构,而不是妄想有专门的时间重构。我们曾经进行的一些大型重构,需要数月甚至数年的时间。如果需要给一个运行中的系统添加功能,你不可能让系统停止2个月去重构。你只能一点点地做你的工作,今天一点点,明天一点点。

如何测试?

我们的时间总是有限的,测试你最担心出错的部分,这样你能得到最大的收益。测试的时候,寻找边界条件,集中火力测试那里!

什么时候取消重构?

如果你感觉到重构失控了,那么最好的办法是取消重构,回到你的安全区去。等你重新能掌控的时候,再来做重构。

重构的团队意识

进行大规模重构时,有必要为整个开发团队建立共识。整个团队都必须意识到:有一个大型重构正在进行,每个人都应该相应地安排自己的行动。

设计模式帮助你重构

学习设计模式可以很好地帮助你重构,它能在适当的场合帮助你承载复杂的业务。但你不应该简单地了解,而是要多对比各个设计模式之间的区别,它们解决了什么问题,适用于什么场合。

技巧篇

不要出现重复代码

当出现重复代码时,你应该提取出公共方法。我想这个说得已经足够清楚了,当出现重复代码的时候就需要想想:我是否需要抽离出重复的代码?

不要出现过长、过短的函数

当函数过长,你应该根据业务逻辑提炼出多个函数。那一个函数多少行算是长呢?按我个人理解,一个函数在 20-50 行是比较合适的。但这也只是一个经验值,最根本的判断标准是:别人阅读你的代码的时候,是否能很清晰、很方便地读懂。 如果你写得很长,但是别人读得时候很舒服,那么也可以。

要注意函数过短也会带来阅读的困难,他会让你多次跳转,打断你的阅读思路。所以如果一个函数内容过短,你需要考虑是否去掉这个函数。简单地说,你还是应该根据业务逻辑结构化,将每块业务逻辑放到合适的函数中。

不要出现过大的类

当类过大,你应该考虑是否能拆分出多个类。或者你应该考虑,你的类抽象体系是否出现了问题。一个过大的类与过长的函数一样,会让人感觉到压抑、难于读懂。

不要让参数过长

当参数列过长,你应该使用对象参数。

提炼发散式变化

因为一个变化,而需要修改多个地方,这说明出现了发散式变化,你需要考虑将变动的代码合并在一起。

提炼对象

总是绑在一起出现的数据,需要把他们提炼到一个独立对象中。

引入解释性变量

不要让你的变量或表达式没有语义,必要时引入解释性变量。很多人会习惯性地用 flag 去承载一个表达式的值,但这并不是一个好的习惯。变量命名还是应该更加语义化,这样我们能更加清晰地明白这个变量的作用。

搬移函数

一个函数被另一个类调用得很频繁,那你可能得考虑把这个函数搬移到另一个类中。

搬移字段

一个字段被另一个类用得很频繁,或许你改考虑把这个字段搬移到另一个类中。

提炼类、简化类

某个类做了应该由两个类做的事情,此时应该提炼出一个新类,然后用组合关系组合起来。这其实与 SOLID 原则想契合,一个类应该是单一职责的,如果某个类做了两个类的事情,那说明其承担的职责就复杂了,因此需要抽离出一个新类出来。

而如果一个类并没有太多内容,这时候就应该考虑是否去掉这个类,优化整个类结构。

文章首发于公众号「架构师指南」及个人博客 shuyi.tech,欢迎关注访问。

参考资料

posted @ 2021-02-25 09:27  陈树义  阅读(458)  评论(0编辑  收藏