58招才猫重构总结

58招才猫重构总结

招财猫系统因为历史原因很是庞大冗余，业务流程特别复杂，最近参加了58招才猫的重构，总结重构的以下几点：

• 兼容旧的代码
• 业务层抽离
• 边际值判定
• 日志处理
• 对外接口要用户友好
• 异常处理
• 测试用例
• 代码规范
• 接口文档

---

1.兼容旧的代码

因为以前的代码正在良好的运行，因此新的代码在实现重构的情况下，测试通过项目上线后为了防止异常情况紧急切回旧接口

解决方案

实现一个selector，维护一个url集合，通过判断url是否在集合内来选择走新的controller还是旧的controller

处理结果

实现了一个自由控制新旧接口切换的开关

2.业务层抽离

原来招才猫中没有业务层，项目太过臃肿庞大。

解决方案

根据情况将业务内容分为代理和微服务两个部分，代理部分实现外部的服务调用，微服务部分根据业务划分出不同的微服务

处理结果

实现了业务层的分离，使主服务只是简单的跳板作用，同时业务的划分有利于程序员对业务的理解和职责划分，增强项目的可协作性，减少新人的学习业务成本。

3.边际值判定

很多接口只能满足特定的情况，未考虑传入异常数据或者脏数据的情况

解决方案

在接口前直接对参数进行检查，throwCheckException并返回异常情况和参数同时记录到日志中，以便于将来进行日志数据分析。

处理结果

异常数据进入接口会抛出检查时异常

4.日志记录

原来的日志记录不规范，怎么记录的都有，有的只是catch了异常并打印，而且使用的都是同步日志

解决方案

统一日志处理规范，每个请求生成一个traceID用在整个程序运行流程，全部使用异步日志处理，出现异常时记录数据的输入，类名方法名和异常的内容。

处理结果

日志记录的规范完整，能快速定位错误，记录速度提升最少30%。

5.对外接口要用户友好

有的接口用户使用的比较痛苦，不能直接返回用户想要的结果；只根据数据库返回结果。还有的接口在方法内调用同一个微服务多次

解决方案

在原有的接口下增加用户友好的接口，优化微服务的调用逻辑

处理结果

增加用户对底层接口的调用，减少程序员造轮子的冲动；同时减少程序的响应时间。

6.异常处理

原来的异常处理大多是将异常打印到日志

解决方案

统一的异常类定义并对异常进行分类和主动捕捉，记录异常的类名、方法名、输入参数和异常的具体信息到日志

处理结果

通过化被动为主动的异常处理使异常更加可控，同时能快速定位异常并便于异常处理。

7.测试用例

在写完自己的接口后还是要写点用例测一下

处理结果

增强代码的健壮性

8.代码规范

老生常谈的代码规范，简单而又困难；最近scala用的多，代码简洁优雅但是可读性还是差一些

处理结果

java还是一门工程语言，有时候可读性还是挺重要的

9.接口文档

曾经最讨厌的两件事：看别人的烂代码和写无聊的文档。看别人的代码时多么希望有一份清晰准确的文档放在我的面前~

处理结果

新写的代码每个接口对应一份最新最全的文档