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

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

[[336600]]

 1.为什么需要我们重构

  • 重构可以提高我们在写作编码时候的速度
  • 重构可以让代码更加的容易理解,方便其他人接手的时候,能够快速的上手
  • 重构可以找出我们代码里面隐藏的一些不易察觉的Bug,进而在之后的运行的过程中,能减少很多不必要的麻烦。

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

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

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

2.1 重复代码

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

  1. @RequestMapping("regist"
  2.     public Map<String,Object> registUser(HttpServletRequest request, HttpServletResponse response,String userName,String passWord){ 
  3.  
  4.         Map<String, Object> map = new HashMap<>(); 
  5.         //校验验证码是否正确 
  6.         if(PropUtils.checkCode(request.getParameter("Code"))){ 
  7.             //如果校验成功 
  8.             map.put("state",0); 
  9.             map.put("msg","验证码正确"); 
  10.         }else
  11.             map.put("state",1); 
  12.             map.put("msg","验证码错误"); 
  13.         } 
  14.  
  15.         //此处保存帐号密码 
  16.  
  17.         return map; 
  18.     } 
  19.      

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

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

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

2.2 巨长的参数

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

  1. 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.如何写出优雅的代码

  • 可读性高
  • 逻辑清晰
  • 高内聚,低耦合
  • 学会应用你所学的封装,继承,多态
  • 已测试

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

 

责任编辑:武晓燕 来源: Java极客技术
相关推荐

2023-05-14 22:25:33

内存CPU

2023-03-27 07:39:07

内存溢出优化

2020-07-01 09:07:52

SQL索引语句

2021-06-11 17:04:55

Loki开源日志

2021-01-30 10:58:29

React应用程序开发

2019-04-16 10:05:52

996公司互联网

2021-10-19 07:06:27

服务器Kubernetes集群

2019-03-25 18:33:37

CIOERP不靠谱

2014-08-28 09:48:41

2021-07-05 22:09:53

面试官CollectionsJDK7

2021-02-23 10:36:09

Linux命令kmdr

2019-05-30 06:37:38

网络故障网络协议网络

2018-05-23 11:43:59

数据库

2024-02-27 18:09:22

Linux命令glow

2021-02-17 10:31:27

MySQL磁盘数据

2021-12-03 11:57:27

代码##语言

2020-05-29 08:14:49

代码Try-Catch程序员

2020-05-06 07:59:20

管理职责素养

2014-06-11 17:57:00

代码IDE

2021-12-31 18:24:45

ThreadLocal数据库对象
点赞
收藏

51CTO技术栈公众号