1。为什么我们需要重构？重构可以提高我们编写代码的速度。重构可以让代码更容易理解，也方便别人接手，能够快速上手重构，可以找出我们代码中隐藏的一些无法察觉的bug，进而在后续的运行过程中，可以减少很多不必要的麻烦。在《重构：改善既有代码的设计》中，重构的目的是为了让软件更容易理解和修改。与上一个相比，是性能优化，没有改变组件的行为，只是改变了内部结构，重构后的软件功能还是一如既往。而阿芬亲身体验过一些人的代码。先不说这个功能实现的好不好。至少你可以对必要的方法写一些评论。上面写的是这里用于教师信息的导入，完成教师信息的分类导入和基本查询。也许你中间做了很多业务操作。你不需要像刚开始工作的朋友那样。评论写在上面，但还是有必要评论的。之前阿芬接手的一个项目，除了在配置文件里从头到尾写了注释，估计是百度写配置的时候加上的。注意，没有评论，看到的阿粉叫崩溃。2.需要重构哪些代码2.1重复代码最简单的重构代码，阿芬给大家放个片段，如果我们有一个注册和一个登录，@RequestMapping("regist")publicMapregistUser(HttpServletRequestrequest,HttpServletResponseresponse,StringuserName,StringpassWord){Mapmap=newHashMap<>();//检查验证码是否正确if(PropUtils.checkCode(request.getParameter("Code"))){//如果验证成功map.put("state",0);map.put("msg","验证码正确");}else{map.put("state",1);map.put("msg","验证码错误");}//这里保存账号密码returnmap;}大家可以看看上面的代码，是不是有很多地方可以直接封装这些代码，毕竟你学的是Java，如果你不会封装方法，你八级还不是一个合格的程序员吗？所以我们把这段代码抽取出来，形成一个方法。我们也可以使用IDEA的快捷键ExtractMethod来提取我们重复的代码。我们在使用这段代码的时候，直接调用这些内容即可，不需要直接拿过来，复制粘贴，然后重新组合代码什么的，直接调用提取出来的方法就可以实现我们的功能。上面分别提到了校验验证码正确性的内容。我们注册的时候有时候需要这个验证，有时候登录的时候需要这个，那么就是一样的验证。你这相当于写了两次。如果你不做抽取，那么最简单的一种代码冗余就会出现在你身上。那么这个时候，我们是不是可以通过ExtractMethod把代码抽出来一个方法封装起来。当我们需要这段代码的时候，我们可以传递这个参数，返回我们想要的数据，对吧？2.2超长参数为什么阿芬把这个放在第二位，因为这也是人们在写代码时有时会遇到的最常见的问题。对于很多刚入职的年轻人来说，传入的Parameters，那是一种恐怖，一行两行都满足不了，例如：HttpServletRequestrequest,intpage,intlimit,HttpServletResponseresponse,Stringoauthuser,StringcupboardId,StringboxId,Stringupboxuser,Stringsex，intage，大家看看这个，如果说写完之后，生成注释的话，注释上就知道这个方法里面的参数是什么了。你标准化了，你也能知道，但是你给个乱七八糟的名字，那么多参数，谁看到谁疯了diss你。我们该如何应对？这个时候你是不是忘了object了，这个object不是另一个object，有了object，我们就不需要在我们的多参数函数中传递我们需要的东西了，我们只需要传递给就够了，使得函数可以从中得到它需要的东西，这样就完全OK了，大家也经常在这个内容中用到它。比如我们在使用Mybatis的时候，是不是经常会选择在resultType中传回一个对象，如果没有对象，就传List。所以，如果你的参数太长，那么你应该需要考虑是否优化一下。2.3注释太多，代码很low。有粉丝说是这个意思。你有没有发现，有的时候，看到评论，满心欢喜，觉得上个哥们好厉害。说的很清楚了，但是看到下面的代码，有种想“一起爬山”的感觉，还有写注释需要注意什么？注释的形式是统一的，就是我们的注释尽量写的一致，文档注释就是文档注释，语句注释就是语句注释，配置注释就是配置注释。评论一定要简明扼要，内容简单明了。评论的数量是必不可少的，但不应该太多。在实际的代码规范中，要求注释占程序代码的20%左右。注释是代码的“提示”，而不是文档。2.4一个很长的函数。当我看到这个太长的函数时，我并没有什么感觉。为什么函数的过程不太好？《重构：改善既有代码的设计》的第三章我看了好几遍。全书大体内容如下：功能短的对象会活得更好，活得更久。不熟悉面向对象的人，往往会觉得对象程序中只有无穷无尽的委托，根本不进行任何计算。生活在这样的程序中直到多年后你才会知道这些小功能有多么有价值。“间接层”的所有好处——可解释性、共享、选择。这一切都由小功能支持。这段话是出自书上，那么这是什么意思呢？其实说白了就是你的一个方法里面逻辑写的太多了。由于公司代码保密，阿芬不能给你截图，但是这里说的是你在方法中的一个方法中写了1000多行代码。真的有那么复杂吗？老实说，不能排除这种可能。毕竟程序是多变的，但是需要自己考虑吗？如果你写一个方法，很多逻辑都是在方法中处理的。然后推几次滑轮，一个方法还没有结束，那么对于接下来的维护人员来说，不仅仅是维护人员，三个月后你会看你写的代码。你确定你能保养好吗？而我们需要做什么？组织逻辑，分解成不同的小函数（小方法）。提高可读性，让我们以后的代码维护更容易维护和处理，不是吗？3、如何写出可读性高、逻辑清晰、高内聚、低耦合的优雅代码学会学以致用封装、继承、多态都考验到了这一点。阿芬希望每个人都能写出足够优雅的代码，而不是像阿芬那样，因为代码碎片化差点被公司开除。
