谈谈为什么需要重构与封装

为什么需要重构？

通常重构的出发点是基于代码冗长或者代码可读性低，频繁出现bug或者bug排除极难分析

重构的前提是不能改变原有业务逻辑，一般解决方式采用可读性高，逻辑清楚和 可扩展的代码来解决. 脱离原有业务逻辑与功能的重构叫做新增

重构的工作该在什么时间去做？

当你的业务逻辑代码开发完毕且测试无bug时，可以停下来回头看一看你可能因为赶需求而匆匆忙忙编写的代码。

当你从这个版本刚刚抽出身又投入下个版本时，你可能会来不及做这些事情。没关系,时间总会有的不是在今天也不是明天，但是最好在你不会忘记前。

有些时候你是作为一个"局外人"参考或者阅读其他小伙伴的代码，当你发现小伙伴的代码符合我上面的："为什么需要重构"中的出发点，你可以勇敢的向开发出来的小伙伴提出你的建议，但是前提你已经做好了重构完毕的结果。 因为他的时间也很宝贵不会因为你的凭空设想而放弃手中的工作来听懂你的想法。

如何去重构？

• 代码冗长就采用封装将核心逻辑提炼出方法
• 代码可读性差就采用好的代码表达方式,如：java8的stream 是我简化的一大神器、设计模式等等..
• 频繁出现bug，可以采用部分简明扼要的描述在加上一些逻辑验证判断
• bug排查难，将你把每一步核心逻辑提炼成方法的时候,代码逻辑就变的清晰明了，配合每一步逻辑执行完毕后的log,相信其他不理解当前业务的小伙伴也能快速定位问题。

嗯，这些是我对重构的认知，下面我想写一写对封装的认知。

为什么封装？

封装的出发点很简单，包装内部逻辑的执行将核心数据返回给调用方或者填充调用方给的数据。 这样调用方只需要关心方法的结果，而不需要关注内部的实现方式、数据调用 、数据转换等等。

如何判断哪些代码需要封装?

• 从代码的入参出参，比如用一个用户id去找购买的课程中的课程的章节数据? 这个时候作为调用方只想关注章节数据而不想知道你是通过什么去找到。
• 一个逻辑功能的实现离不开验证判断、数据获取、数据修改,不明白该怎么做的时候先分析你想封装的这段代码属于那部分？他的业务是什么？
• 通过封装细节的实现把提炼出来的描述方法名给到调用方，这样调用方只会知道你的功能，从而不把细节一一暴露。

把细节封装起来是不是不利于理解功能的逻辑？

不会，如果将封装好的方法通过简明扼要的方法表述，其他不理解业务的小伙伴也能知道你的功能逻辑需要哪些数据来支持功能业务的完成，如果小伙伴想了解某一项封装的方法内部实现，可以自主的查询或者参考。

后话

其实写完这些认知的时候，还是自己凭借着开发经验以及遇到的问题来总结的，没有阅读过前辈们的书籍、博客。 当我阅读了《重构改善即有代码设计》这一书后，发现前辈们已经把问题和对策解析的清清楚楚，书中大多的思路与对策比我上文中表述的更加清晰。