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.如何写出优雅的代码
- 可读性高
- 逻辑清晰
- 高内聚，低耦合
- 学会应用你所学的封装，继承，多态
- 已测试
到这里，阿粉希望大家能够写出足够优雅的代码，不会像阿粉一样，因为把代码写的稀碎，最终导致自己差点被公司开了。
