重构一个快不可维护的项目

历史原因，接手了一个一直堆业务逻辑，没有重构过的项目，简单看了一下代码就感觉麻头皮，满目都是一个方法里面大段的代码，阅读起来极度困难,可以合并的类没有合并，导致一个请求回调之后需要发送4个Event，这些都让我感觉重构迫在眉睫。

首先我将重构分为代码质量的重构和业务逻辑的重构,因为业务迭代还在继续，这时候进行大量的业务逻辑重构，肯定为影响业务进度，所以我第一步的工作重点就是代码质量的重构。

代码规范

项目中有很多命名不规范，随便换行，递进，空格，这些小的点，虽然不影响功能，但是很影响阅读，这里为什么强调代码阅读性的重要，这还是我刚到饿了么的时候，思敏大哥和我强调的，好的代码，只需要看一下类名方法名，就应该知道这个类的作用，这样的好处了是增加了可维护性，很多功能，过了一阶段，自己回头看的时候，可以轻松的了解整个代码的功能，而不需要一行一行的看代码,更何况很多情况都是其他人来阅读你的代码.

解耦



这张图把解耦解析的淋漓尽致，子系统、子模块的职责划分。把内在关联密切的功能/实现放在一个模块中，最小化暴露给外部的细节和依赖，是为“高内聚、低耦合”。我们的项目中有很多的工具类中依赖这外部的各种条件，变量，比如说网络请求模块,他的Header头HeaderInterceptor中依赖大量的本地管理类提供数据，平时用的时候没有感觉出问题，但是当我想在另一个子模块想使用网络请求的时候，发现没有环境去获取本地管理数据，他根本运行不了，所以这个时候，我将HeaderInterceptor作为对外接口，让实现网络请求的模块自己去实现HeaderInterceptor然后传进去，这样就完美的解决了网络请求和本地数据的耦合。解耦的自由，可以放心的整体替换模块，这个网络请求库使用不爽，我再换一个，我对外暴露的接口和回调是相同的，快捷拔插,方便的一逼。

函数拆分

函数应该做一件事。做好一件事。只做这一件事。

一个100行的函数，让人感到绝望，我们的项目中真有这样的big function,我花了20分钟才看懂它的作用，其中各种细节，估计现在让作者来解释也需要再看半天。如果一个方法是功能是将请求的数据进行分组=A，然后显示listview=B，再然后隐藏原来的空白布局=C。那么就应该把这3个功能写3个方法，这样在请求的回调里面很清晰的看到

{
A; //数据进行分组
B; //显示listview
C; //隐藏原来的空白布局
}

每个方法只做一件事，除了阅读的方便，还有个好处就是复用,如果你重复的写相同的逻辑，这个时候，你就应该把相同的逻辑抽出来，放大点说，github上的各种库就是这样的轮子。

不过不得不说，重构别人的代码是痛苦的，尤其是看到那些蠢萌的方法,简直想哭。强迫症也是在重构过程中养成的，改完了的代码，让我感觉舒服，放心，满足，一个码农的快乐和骄傲，莫过于此。