重构思考

项目代码重构相关工作思考如下

1. 代码重构首先需要将模块拆解清楚，明确界定功能以及接口，这个工作是代码重构的第一工作
2. 对于单个模块，只需要将定义的模块接口在需要的数据结构暴露。此外，不应该将数据库相关表格定义类暴露，否则模块将很难对数据表字段进行增删。开发者应该意识到暴露出去的公共接口是不能够确定其使用范围，而其中的数据结构也是如此（项目初期并没有感觉，但是对于一个运行几年的程序，你真的敢去更改这些公共字段吗？）
3. 模块内部的分层也是需要慎重考虑，服务可以有很多种组合方式。简单分类就是按照主体和动作，这应该也是划分的思考顺序，对于一个函数我们首先应该考虑这是属于哪种类型的，确定了主体之后就可以将其暂时放到主体下的目录。划分主体对于一些工具类也是如此，如果一个操作与主体关系并不密切，或者说方法本身所做的事情就是一个转换过程（也可能是一个验证过程），这种方式下尽可能用工具类。工具类尽可能用静态方法并且通过命名方式阐述工作。如果你对是否使用工具类还是有困惑，那么以下有几点可以帮助你判断
   1. 方法本身是否依赖其他服务（不包含其他工具类），如果依赖则尽量不使用工具类
   2. 方法本身使用的数据结构是否通用，如果数据结构仅为单个服务内使用，那么就将方法变为private或者封装在内容
   3. 方法的作用范围，能够变为工具类应该是那种其他服务类中大量使用的，如果使用范围不够广那也没必要声明工具类
      方法本身最好使用动词+名词，单独使用动词或者名词都会让方法看起来十分奇怪并且导致他人犯错。
4. 对于方法访问权限声明，实际上只用考虑一点，能不暴露的方法就不要暴露，从责任上来看，你暴露的方法都是需要负责的，也都是需要花费维护成本的
5. 如何决定代码是否需要重构最基础一点就是代码是否不断重复业务逻辑，事实上重构只适用于解决重复和耦合问题，对于性能并不是重构首先关注的。遇到重复代码就抽出重复逻辑，按照主体和作用范围一个接口，最后通过接口进行调用。