编码经验杂记

友好的表单业务的完整流程
页面防止重复提交–> 页面表单验证–>展示loading图–>网络通信问题反馈处理 -->后台防止重复提交–> 后台数据验证–>后台业务处理–>保存数据（处里空格等）–>日志记录错误的详细信息–>展示详细处理结果和说明–>页面根据处理结果引导客户进行业务跳转。

业务优化点

• 尽量减少循环
• 重用资源，充分利用缓存（链接，不易变化的数据）
• 尽量减少异步行为，让流程各步骤串行化
• 充分利用索引
• 尽量保证流程单一，不要掺杂其他流程。（例如，送券的流程掺杂统计过程）
• 对于耗时的操作且不需要同步返回的，放在线程中执行
• 流程中尽量减少系统间耦合
• 在保证事务的情况下尽量把计算结果的流程和使用结果的流程分开
• 表设计尽量减少多表关联查询，让不变的字段冗余
• 尽可能的创建可重用对象
• 并发是高效的，锁降低了并发的效率，甚至让并发变成顺序执行，失去了并发的意义。所以最好的并发是无锁的并发，应该尽量去掉锁。

编码注意事项

• 获取一条记录后，如果没有，是不是应该新建一个，应该慎重考虑。
• 改变代码顺序需要及其慎重
• 并发环境要充分考虑所使用工具类是否线程安全
• 有的接口是基于当前时间的，所以下次调用同样的参数可能就会不幂等，一种解决方法是把当前时间也作为参数传入。
• 处理批量数据时，要处理好单个错误对全部数据的影响
• 新加查询字段时，慎重通过判断null来增加查询条件，这很可能会改变接口的语义

  public ServiceResponse<PaginationResult>  getChannelSkuMappingPageList(@Valid ChannelSkuMappingPageRequest  req) {
         
          if (req.isEmpty()) {
         
              return ResponseTool.success();
          }
  //这个是新加的字段，先前的语义是 没有这个字段也就是null的时候查询所有，如下代码会改变原来的语义
          if(req.getContainSyncProductPlatform()==null){
         
              req.setNotPlatformCodes("1,3");
          }
  }
  

业务流程的稳定性

• 所有参与的接口都必须严格幂等，这样才能重复调用来最快的恢复失败部分
• 每次业务都应有唯一标识，参与的接口都被追踪和记录，这样才能知道业务走到了哪里，可以最快的进行恢复
• 每个错误都应被严格记录日志和通知相关人员，这样才能最快发现问题
• 每个异步任务都应记录进度和状态

拆分服务的界限的一个考量就是可能的访问数量，像c端访问量通常远远大于b端，所以应该把c端，b端分开

流式编程

• 流式编程减少了循环的次数，提升了效率，相当于在一个循环里处理所有数据。
• 考虑流的带宽，可以只是一个对象的带宽，也可以是10个对象的带宽。如果总共需要处理10个数据，带宽为1，如果数据来自数据库，那么就要有10次io，就不如一次10个数据，只需要一次io。所以带宽的大小依情况而定