公司差点因为代码写得差把我直接给开掉

鸭血粉丝· 2020-08-07
本文来自 Java极客技术 ,作者 鸭血粉丝

 1.为什么需要我们重构

  • 重构可以提高我们在写作编码时候的速度

  • 重构可以让代码更加的容易理解,方便其他人接手的时候,能够快速的上手

  • 重构可以找出我们代码里面隐藏的一些不易察觉的Bug,进而在之后的运行的过程中,能减少很多不必要的麻烦。

而在《重构:改善既有代码的设计》说重构的目的:让软件更加的容易理解和修改,而与之前的形成对比的是性能方面的优化,不改变组件的行为,改变内部结构,而重构之后的软件功能还是一如既往。

而阿粉是亲身经历过有些人的代码,咱们先不说这个功能实现的好坏,至少你必要的方法上面能不能写点注释,比如说实现某些功能的时候,你可以在方法的实现上面写上,用于此处教师信息的导入,完成教师信息的分类别导入和基础查询,可能你在中间做了很多业务上的操作,不用像刚刚走上工作岗位的朋友一样,每个方法上面都写上注释,但是必有的注释还是要有的把,阿粉之前接手的一个项目,从头到尾除了在配置文件里面写了注释,估计还是百度的时候写入配置的时候加上去的注释,一个注释没有,看的阿粉那叫一个崩溃。

2.都有哪些代码需要重构

2.1 重复代码

最简单的一个重构的代码,阿粉给大家放上一个片段,假如说我们有一个注册和一个登陆的,

@RequestMapping("regist") 
    public Map<String,Object> registUser(HttpServletRequest request, HttpServletResponse response,String userName,String passWord){ 
 
        Map<String, Object> map = new HashMap<>(); 
        //校验验证码是否正确 
        if(PropUtils.checkCode(request.getParameter("Code"))){ 
            //如果校验成功 
            map.put("state",0); 
            map.put("msg","验证码正确"); 
        }else{ 
            map.put("state",1); 
            map.put("msg","验证码错误"); 
        } 
 
        //此处保存帐号密码 
 
        return map; 
    }

大家可以看一下上面的代码,是不是很多地方我们可以直接把这些代码进行封装,毕竟你学Java的,你不会封装方法的话,你岂不是就不是一个正儿八级的合格程序员了。

于是我们把这个代码抽取出来,就组成一个方法,也可以使用IDEA的快捷键,Extract Method 这样把我们重复的代码提取出来,当我们在使用这段代码的时候,我们就能够把这些内容直接调用,不用在直接拿过来复制粘贴,然后把代码重新组合啥的,直接就可以把这个抽取出来的方法进行调用,实现我们的功能即可。

而上面就单独说这个验证这个验证码正确性这块的内容,我们在注册的时候,有时候会需要这个验证,在我们登录的时候有时候也会需要这个,那么都是同样的验证,你这就相当于写了两次,如果说你不做抽取,那你的里面就出现了最简单的这种代码冗余。那我们这时候是不是就可以通过Extract Method把代码抽取成一个方法,封装起来,当我们需要这段代码的时候,我们把这个参数传递过去,返回我们想要的数据就可以了,不是么?

2.2 巨长的参数

为什么阿粉要把这个放在第二个呢,因为这个也是大家有时候在写代码的时候最容易出现的问题,有很多刚刚初入公司的年轻人来说,那传递的参数,那叫一个恐怖,一行两行都不能满足,比如说:

HttpServletRequest request, int page, int limit, HttpServletResponse response,String oauthuser, String cupboardId, String boxId, String upboxuser,String sex,int age

大家看看这个,如果说你在写完之后,生成注释的话,这样在注释上面还能知道这个方法里面的参数是什么,规范一点的话,那也能知道,但是你如果起个乱七八糟的名称,还这么这么多的参数,谁看到了不是疯狂想diss你。

而我们能怎么处理呢?这时候你是不是把对象忘记了,此对象非彼对象,而有了对象,我们就没必要把我们函数需要的东西用多个参数传递了,我们只需要传递给他足够的,让函数能够从中获取自己需要的东西这样就完全OK了,大家在这块内容也是经常使用的。

比如我们大家在使用 Mybatis 的时候我们在resultType 里面是不是很多时候都会选择传递一个对象回去,而如果没有对象的时候,你去传递List

所以说,如果你的参数过长的时候,那么你就应该需要考虑是不是要进行一下优化了。

2.3 注释太多,代码很low

阿粉说这个的意思是这个样子的,大家有没有发现,有时候,你看到注释的时候,满心欢喜的,感觉就是上一个哥们很给力呀,这注释写的明明白白的,但是看到下面的代码的时候,就有了一种想要“一起去爬山”的心情,而我们在写注释的时候需要注意什么?

  • 注释形式统一,也就是我们的注释尽量都是写的一致,文档注释就是文档注释,语句注释就是语句注释,配置注释就是配置注释。

  • 注释一定简明扼要,内容简单直白,是什么就是什么

  • 注释的数量,注释必不可少,但也不应过多,在实际的代码规范中,要求注释占程序代码的比例达到20%左右。注释是对代码的“提示”,而不是文档。

2.4 非常长的函数

话说阿粉在看到这个过长函数的时候,并没有什么感觉,为什么函数过程不太好呢,阿粉把《重构:改善既有代码的设计》中的第三章硬生生的看了好几遍,书中大致内容如下:

拥有短函数的对象会活的比较好,比较长. 不熟悉面向对象的人,常常觉得对象程序中只有无穷无尽的委托,根本没有进行任何计算. 和此类程序共同生活数年之后,你才会知道, 这些小小函数有多大价值. "间接层"所能带来的全部利益- 解释能力,共享能力,选择能力.这都是由小型函数支持的.

这段话是出自书中的,那么这是个什么意思呢?其实说白了,就是,你的一个方法里面,写了太多太多的逻辑,阿粉因为公司代码涉密的关系,不能给大家截图,而这里所说的就是,你在方法里面一个方法写了1000多行的代码。

真的有这么复杂的么,说实话,不排除这种可能性,毕竟程序是多变的,但是你是不是需要自己想一下,如果你写了一个方法,方法里面处理了一大堆逻辑,然后滑轮使劲好几下,一个方法没结束,那么对接下来的维护人员,就不单单说维护人员了,就是你自己三个月之后来看自己写的代码,你确定你能维护好么?

而我们需要怎么做?

把逻辑整理,分解为不同的小函数(小方法)。提高可读性,这样,我们在之后的代码维护也好维护,处理也好处理,不是么?

3.如何写出优雅的代码

  • 可读性高

  • 逻辑清晰

  • 高内聚,低耦合

  • 学会应用你所学的封装,继承,多态

  • 已测试

到这里,阿粉希望大家能够写出足够优雅的代码,不会像阿粉一样,因为把代码写的稀碎,最终导致自己差点被公司开了。