优化后的代码怎么保障系统与原有功能的一致性?
考虑各系统和模块间功能的耦合性
先和当前优化点业务最熟的人员做沟通,询问改动点将会涉及到哪些系统及模块. 尤其当改动点是各系统及模块共享使用的东西时.
举例说明:车承保和公共在用Redis协同管理代理人信息,当对车承保做Redis优化,比如原有Redis主键名命名有不规范,直观地修改Redis主键名后会导致公共无法存取车承保对Redis设置的新缓存.
优化前要充份理解原代码的意图
只有对原代码充分理解后,才能开始动刀.不然很有可能因为原有某个细节上的操作,导致整套流程在特殊场景下阻塞或异常.
优化中尽量抽取复用性代码
随着时间的推移,人员的流逝,由于后来者之前代码的不熟悉,往往会考虑编写新的方法去实现原来已经存在该功能的方法,在考虑到有风险的前提下,尽量使用统一的出入口复用代码.
把不规范的方法名改成直观易懂的方法名.但尽量不要改动controller/action的类名和方法名(就算不合理),因为受限于框架本身原因,前台的js或dw可能会引用到该controller/action
合理地使用log日志.
优化中定期用SVN做版本归档
优化后一定要自测
尽可能多地考虑各测试分支场景,尤其是那些边界值的测试.且自测完后和测试组沟通影响地改动点.
举例说明:
xxx
优化后尽量做性能比对
如果改动的是性能问题,能用柱状图或饼图显示前后性能比对,可以用loadrunner或jmeter等压测工具重新压测
举例说明:
描述网页按钮响应时间从几秒降低到了几秒.
Sql优化
尽量减少和数据库的交互,对常用数据或冷数据做缓存处理.
参考之前二代的ppt
使用任意形式流程图
不拘泥于形式主意,也不一定要美化PPT,只要能用图文清晰地表达已经理解的信息,就算目前自身无法解决当前问题,仍可用流程图做个汇总,让后置介入者尽量不要从零开始.
举例如下:
销管系统在手续费打包，代理人修改之后需要请求公共系统清redis缓存 , 现整理数据流图如下:
l 公共主要方法: BWriteEmpInfoServiceImpl.saveOrUpdate(入口webservice方法)
l 车承保主要方法: BWriteEmpInfoServiceImpl.saveOrUpdate(入口codelist方法)
酌情考虑版本大小
考虑优化周期和版本合并时对当前系统的影响大小和复杂性
考虑灾备措施
即是否会因为本次优化出现生产事故后紧急回退,数据库和业务代码.
举例说明:数据库新增或删除字段,没有考虑到数据补遗和在途数据,上生产后突发异常,考虑如何合理地备份和回退数据