代码习惯

  1. 复制对象时（大多用于返回模型转换，如 entity→bo bo→resp），在目标对象中写对源的复制；因为这种情况大概率目标对源是一种依赖关系，数据的来源应该基本从源对象来的。此种处理可以方便的梳理对象之间的关系，尤其在业务复杂后方便梳理；

    • 可以写一个公共的泛型接口，并设置默认复制方法，如BeanUtil.toBean之类，保持更大统一；

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      /**
       * 从源数据复制对象，需保证字段，类型一致
      *
      * @author liukewen
      * @since 2022/8/3
      */
      public interface CopyFromSource<S,T> {

          /**
           * 复制对象值
          * @param s
          * @return
          */
          default T copy(S s){
              BeanUtil.copyProperties(s,this);
              return (T) this;
          }
          default T copy(S s, Consumer<T> consumer){
              T copy = copy(s);
              if (consumer !=null){
                  consumer.accept(copy);
              }
              return copy;
          }

      }

    • 反例：在业务中到处使用 Bean.copy， 将会导致有一个地方修改时难以找到利用此对象创建的类，改起来十分麻烦；

    • 对象差异大的尽量不要用这个，因为，久了你也不知道哪些字段是复制了的，又得看代码逻辑；

  2. 禁止使用map作为接口的返回及入参，map导致接口语义不清晰，需要跟踪代码才能清楚含义，非常不利于维护；

  3. Vo返回的数据字段一定是要都有意义的，没有意义的字段会导致接口语义不清晰（跟map一样）；

  4. feign 传输时入参返参不得出现无意义的字段，否则会导致业务调用者不清楚是否有相应的入参数据或返回数据；

  5. 合理使用继承关系，具有相同意义的对象或有联系的对象应当使用继承，在后期维护时只需要修改其中一处便可以；

  6. 入参具有相同意义都需要实现相同逻辑的可以考虑抽象类或接口，并在相同的逻辑处实现默认方法；
    eg: 管家必传医生ID，医生后台赋值的情况，可以利用接口的性质统一校验；

  7. 凡是相同或及其相似代码的处理逻辑一致的必有需要调整的，避免出现改一处都需要改；

  8. Service层需要无状态，上下文相关的东西赋值应该在controller中做；

  9. 规划后台服务模块时划分好功能对应的模块，服务之间要在数据库之间隔离，通过service调用；

  10. Conroller的@RequestParam尽量写上，否则框架会做更多的处理匹配字段对应(另外的sm框架，反射都无法做到)；

  11. 模型之间最好要有关联，不能都只在业务中体现；

  12. 获取外部的接口必须统一管理，在统一的jar或公共模块中处理，不能在各自的业务中去调用，否则到处都会有相应的代码，当需要调整的时候不容易找全调用接口；同时也没办法统一管理token等。

  13. 枚举类型不应该用数字表示，更不应在程序中用魔法值等于，这样会造成类型引用不清晰；

2. 框架搭建

  1. 抽离公共工具-模型包，项目中所有地方都用到的基本模型、工具、异常定义等单独放到一个包（不依赖spring等，只有模型）；
  2. 抽离公共配置 starter 并将公共信息定义好（比如租户、登录人、流水号、公共Feign等 信息的拦截及配置）；
  3. 抽离数据库持久层starter 配置好数据库信息和持久层工具（mybatis、mybatis-plus等），需要用的地方直接依赖，不访问数据库的可以不依赖此（如web工程）；
  4. eureka-client可以配置为starter，并做好配置，配置好公共配置，其余业务模块直接引入配置好应用自己的配置即可(spring.application.name server.port);
  5. eureka-client可以配置好Feign和Hystrix ，使得所有的Feign和Hystrix具有相同的全局配置；
  6. Zuul或SpringCloud Getway单独部署一个工程作为全局网关，网关中可以配置具体的服务名的访问规则，实现全局负载均衡和初步鉴权；
  7. 网关鉴权中可以整合Spring Cloud Security，以Oauth2方式鉴权；
  8. SaaS系统的租户可以通过前端差异化处理，也可以通过网关的ip来源不同在网关中处理；