代码优化——空间换时间，减少DB操作

摘要: 今天对以前其他同事的代码进行了优化， 有了一些新的 记录一下，各位大牛们如果发现什么问题，或者有更好的见解，欢迎进行讨论

优化前

1. 根据前端传入参数 查询符合条件 的 订单--- 得到订单列表

2. 从列表中 汇总 平台订单code--- setCodes

3. 根据codes 获取到，平台订单信息

4. 循环 平台订单 {

1. 汇集平台订单信息

2. 根据 平台订单code，查询 订单信息（ 此处可优化；多余， 上面已经有相关订单数据）

3. 根据订单的id 获取订单的衣服 （此处 可优化）

4. 根据订单Id 和管家 类型 查询 订单的管家备注 （此处 可优化）

5. 根据订单ID 和 用户备注类型，查询订单用户备注 （此处 可优化）

6. 查询订单的 快递信息 （此处 可优化）

}

此处的问题：

1. 代码问题

过度使用 spring 的@RequestParam注解，且每个参数 都 指定了value， 和对于的变量

该列表查询有 16 个参数，按上述 方法，陈列了16个参数赋值代码，，，代码复杂，容易出错

一次性将16参数传给了service，，，使 一个方法 达到了20多个参数，容易出错

if else 的形式 赋给了map，作为参数 传给了 dao

此处的建议： 把参数的问题，通过 封装的方式 直接从request解析出参数，并返回map，把复杂逻辑统一封装起来（详见 RequestUtil的parseRequestParamterMap）

优点，所有参数处理一行代码带过，替代了少则十几行，多则上百行的代码；只要封装逻辑稳定，所有地方的错误率极低；可以按照需要 自动提供 _like _Set的扩展功能；

缺点，1, 封装逻辑 按需封装；2 前台需要 跟model的属性 强一致（这里是可以的）

2. for循环嵌套 查询，而且是5次查询 ，也就是说 如果 for循环N次 需要访问5N次库。可怕至极

优化后：

1. 根据前端传入参数 查询符合条件 的 订单--- 得到订单列表 orderList

2. 参数准备

for 循环 订单列表 {

转换成orderMap key为gorderCode

得到以gcode为key 订单对象为value的map -- mapOrders

得到 id的list -- orderIds

得到gcode的Set--codes

}

数据准备

根据codes 获取到，平台订单信息

根据orderIds 获取 orderClothesList 并转分类汇总为Map orderClothesMap（详见MTMaps.list2MapGroupByKey）

根据 orderIds 获取 orderRmarkList 并转换成Map orderRemarkMap , key为 orderId_type(详见MTMaps.list2Map)

根据 mobileList 获取 courierEntryList 并转换成Map courierEntryMap, key为mobile_projectId

4. 循环 平台订单 {

1. 汇集平台订单信息

2. 根据 平台订单code，获取订单详情：mapOrders.get(gorderCode)

3. 根据订单的id 获取订单的衣服 : orderClothesList.get(orderId)

4. 根据订单Id 和管家 类型 查询 订单的管家备注 :orderRemarkMap .get(orderId_hkType)

5. 根据订单ID 和 用户备注类型，查询订单用户备注:orderRemarkMap .get(orderId_hkType)

6. 查询订单的 快递信息:courierEntryMap.get(mobile_projectId)

}

总结：

此处利用了 数据结构，牺牲了空间， 通过减少DB访问次数，换取了时间。

扩张：

当数据量大的时候，可以 启用多线程：

1，任务很多，分任务查询

2，单任务数据量大，每个线程 负责一页 查询，然后汇总。

3， 等所有任务线程结束后，开始计算。计算也可以根据实际情况，进行并发化。