dajx-api
1. 发送短信的方法未合理的封装使用
问题: 未合理的封装使用,赋值粘贴的产物,无法高效的复用,不易维护
优化方案: 封装短信工具类
优化状态: 待确认
现有代码部分截图:
2. 接口及内部代码调用的返回参数格式未使用统一封装的Response类
问题: 一个统一的返回数据格式,体现在代码中,却是每一个Controller和Service都各自写了一遍,复制粘贴用的淋漓尽致,主要问题是代码冗余,接口公共返回不易扩展
优化方案: 这里牵扯到需要修改的文件非常多,一个一个文件,一个一个方法的修改,从Controller到Service都要改,逻辑简单,工作量巨大
优化状态: 待确认
现有代码部分截图:
3. Service类的方法调用,在编辑器中无法索引(如PhpStorm无法使用Ctrl+鼠标右键找出所有使用当前方法的位置)
问题: 由于Service类的基类BaseService是采用的单例模式,Controller只能使用BaseService类的单例模式去获取Service类的实例,导致Service类的方法调用,在编辑器中无法索引(例如j截图中的ActiveService类的Join方法,完全没有办法通过编辑器的索引优化去找到那些地方使用了这个方法,如果我要修改ActiveService类的Join方法该怎么办?会影响到其他什么地方完全是未知,导致我不敢对ActiveService类的Join方法有任何修改)
优化方案: 这里牵扯到需要修改的文件非常多,在编辑器中全局搜索::getInstance()这样的字符串,一个一个文件,一个一个方法的修改,逻辑简单,工作量巨大
优化状态: 待确认
现有代码部分截图:
4. 生成订单编号的方法,没有使用统一的一个方法
问题: OrderService类的function generateNumber()原本和OrderManager类的function generateNumber()逻辑是差不多的,因为正式服上发现重复订单号的BUG,所以OrderService类的function generateNumber()是修改后的版本,安全性更好,性能相对应会差一点,问题还是没有统一进行封装
优化方案: 优化OrderService类的function generateNumber(),删除OrderManager类的function generateNumber(),修改所有使用OrderManager类的function generateNumber()为OrderService类的function generateNumber()；
优化状态: 待确认
现有代码部分截图:
5. BeadhouseService类的function info()中存在多余的代码
问题: 这个try catch写了跟没写一样
优化方案: 删除多余的垃圾代码
优化状态: 待确认
现有代码部分截图:
6. 在循环中操作数据库,可以优化成批量插入
问题: 如图
优化方案: 可以优化成批量插入
优化状态: 待确认
现有代码部分截图:
7. 全局格式化代码
问题: 如图,编辑器会显示波浪线,看着不习惯
优化方案: 全局格式化代码,对系统过的稳定性会不会造成风险,暂时未知
优化状态: 待确认
现有代码部分截图:
8. 接口缺少必传参数时,报错未知错误
问题: 接口缺少必传参数时,报错未知错误
优化方案: 修改为返回对应的错误信息
优化状态: 待确认
现有代码部分截图:
9. 封装一个发送邮件的类,集成到项目中,接口出现异常时发送邮件给开发人员
问题:
优化方案: 方便开发人员及时分析异常原因,比如某个接口报错未知错误了,开发人员就及时的知道了
优化状态: 待确认
现有代码部分截图: 大概是集成发送邮件在这个位置
10. Security类的function switchKey()是未完善的多余的代码
问题: 全局搜索过,没有任何地方使用function switchKey()
优化方案: 删除多余的垃圾代码
优化状态: 待确认
现有代码部分截图:
11. OrderService、PayService类的获取订单支付参数应该进行统一封装
问题: 获取订单支付的方法没有进行统一封装，不易维护
优化方案: 统一获取订单支付参数的方法，方便扩展也方便维护
优化状态: 已确认-正在优化中-已提交-待测试
小结
以上是dajx-api项目目前看到能优化的,更多的如Service类和Model类的代码复用性不高,业务逻辑未抽象的特别清晰,查询数据库的语句随处可见的复制粘贴,这些,可能需要完整的对系统现有的应用功能做重构分析与设计,制定开发规范,抽象核心业务逻辑形成一套技术方案出来才算优化,不然也只能叫重写了一遍
