前言
有好几天没有更新了，今年过的格外快些。眨眼间已经到了下半年。嗯，切入今天的正题。今天给大家推荐一本好书《重构》。说起重构，在技术圈中总有一种现象，就是不愿意接手别人的代码，不愿意维护老系统。甚至想着每进一个公司都是从零开始设计系统。殊不知，在职业生涯中，我们参与的系统更多的不是从0到1，而是从1到100的演进。在这期间，我们不免会接触别人的代码，在老系统中进行日常迭代。或许是随着时间的推移，技术的进步。当初的好代码也慢慢的散发出坏味道。当你臭骂着这段代码，却又不知如何进行重构时。《重构》中就有你的答案，它会告诉你如何去除，发现，挖掘代码中的坏味道。让之重新焕发清香。
代码坏味道
如果把重构分为两步，那么第一步就是发现代码中的坏味道。发现坏味道可能仁者见仁，智者见智。但在《重构》中，作者根据经验给出了自己的答案。下面简单列举几个:
1. 重复代码
不知道你看到重复代码的心情是怎样的？在IDEA眼里是用波浪线着重标识的。在作者眼里，重复代码简直就是坏味道代码的典型。在我眼里，恨不得挽其袖子立马将其修改。
2. 过长函数
这类问题，在接口实现中，简直就是重灾区。一不小心就会在函数中写上好几百行，甚至上千行的代码。从功能角度来说，也没啥毛病。但是对于后期维护，代码理解，却是灾难性的。如果把一个长函数当作是一篇文章。一篇上千字没有章节的文章，哪怕文章再好，都勾不起我的兴趣。
3. 过长的参数列
从刚开始学编程时。我们就知道，需要把函数需要的东西以参数的形式传递的到函数，但过多的参数列也有着难以理解，数据不一致的诟病。每新增，减少参数时，都要对函数本身进行修改。隐式的造成了诺大的风险。
4. 过多的注释
在之前的文章中曾经说过，写注释是程序员需要养成的好习惯。但过多的注释，势必也是一种坏味道。这里的坏味道。并不是指注释本身。而是说，注释下的代码。需要过多注释来解释的代码，说明代码本身并不足以清晰的表达其作用。这样的代码是需要进行重构的。
上面列举了几个坏味道，如果你仔细翻阅《重构》，会发现更多的坏味道。再仔细看看代码，或许你会闻着一股难闻的味道。追求完美的你，恨不得立马将其进行重构。
如何重构？
现在我们已经学会识别代码中的坏味道。现在就应该上手来剔除它。在书中，作者不仅给出了大型重构的经验，并且详细到代码层面的例子。每一种手法，都记录了重构动机，做法以及对应的范例。
1. Rename Method(函数重命名)
好的代码是会说话的，一个好的函数名就能够很清晰的表达该函数的作用。我们在命名函数时，尽量要能表达该函数的作用。而不是使用更多的注释来解释该函数的用途。
2. Extract Method(提取方法)
还记得上面重复代码，超大函数的诟病吗？在重构这类代码时，我们通常会采用该重构手法。抽取成公共函数，细粒度函数。这样也利理解与维护。这与现在的微服务思想不谋而合。当提取的方法粒度足够细，其复用程度也就更高，可维护成本，修改风险降到最低。
3. 嵌套条件语句
不知道你看到多层嵌套条件语句是怎样的心情。我肯定是晕的。在日常编码中，我们通常会对一些关键代码加一些规则才予以执行处理逻辑。在这种场景中。我们应该将不符合规则的直接返回。只有都符合规则的才能执行业务。而不是使用多层 if else 来进行判断。
例如:
if(规则一){
if(规则二){
if(规则三){
System.out.println("成功");
}else{
return "不符合规则三"
}
}else{
return "不符合规则一";
}
}else{
return "不符合规则一";
}重构后:
if(!规则一){
return "不符合规则一";
}
if(!规则二){
return "不符合规则二";
if(!规则三){
return "不符合规则三";
}
System.out.println("成功");还有更多的重构手法。等待着你去解锁，去掌握。
最后:
-
或许你看完《重构》后，你可能会觉得自己的项目与其重构还不如重写呢？但，对不起，没有哪个公司会愿意专门花费时间来让你重写系统。我们只能一步一步的去重构。在日常迭代中去重构。当添加新功能时，想想这部分代码是否有需要调整。再进行调整，调整后，一定要写测试类，进行回归测试。
-
或许看到这里，你可能会问？文章中说的大部分是重构手法。如果从零设计，编码。这些技巧还用得着吗？答案是肯定的。我甚至认为更应该看看这本书。因为这样就可以从”源头”减少代码的坏味道。
PS: 公众号內回复『重构』，即可获得一份高清电子版！
嗯。周末愉快！
相关阅读:
《说说Java日志》
扫码关注，一起进步
个人博客: http://www.andyqian.com
1941
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
