自我日常开发规范

2022-03-25 13:31:05 阅读：179 来源： 互联网

标签：shop childOrder return 自我 Long 规范日常封装 public

1、controller定义

接口定义时，尽量向resultful 风格靠拢

比如创建一个用户的API，定义好统一的前缀，按照模块化设置名称，比如@RequestMapping("user")
增删改查接口不要定义为 addUser delUser这样

使用 @GetMapping、@PostMapping 比较简洁

@RestController
@RequestMapping("users")
public class UserController {

   @GetMapping("/status/check")
   public String status() {
      return "working";
   }

   @GetMapping("/{id}")
   public String getUser(@PathVariable String id) { 
   }

   @PostMapping
   public String createUser() {return "HTTP POST was called";
   }
  
}

2、封装方法形参

调用其他方法时，参数三个以上必须封装成对象，禁止多个参数传递，容易出错，并且看着难受

@RequestMapping(path = "getVehicleList", method = RequestMethod.POST)
public Response getVehicleList(
        @ApiParam("车辆品牌ID") @RequestParam(name = "brandId", required = false) Long brandId,
        @ApiParam("车系ID") @RequestParam(name = "seriesId", required = false) Long seriesId,
        @ApiParam("车型ID") @RequestParam(name = "modelId", required = false) Long  modelId,
        @ApiParam("vin") @RequestParam(name = "vin", required = false) String vin,
        @ApiIgnore Page page)  {
    List<Vehicle> vehicles = vehicleHandler.getVehicleList(brandId,seriesId,modelId,vin,page);

3、封装业务逻辑

每一个方法做好一件事，禁止在一个方法体内堆砌代码，完成所有业务逻辑
主方法中调用这些方法，添加注释达到一目了然的效果

下面是一个很好的例子，一个大业务里面有多个小业务，不同的业务调用不同的 service 方法即可，后续接手的人即使没有流程图等相关文档也能快速理解这里的业务

@Transactional
public ChildOrder submit(Long orderId, OrderSubmitRequest.Shop shop) {
    ChildOrder childOrder = this.generateOrder(shop);
    // 校验优惠券
    orderAdjustmentService.validate(shop.getOrderAdjustments());
    // 订单商品
    orderProductService.add(childOrder, shop);
    // 处理订单地址信息
    processAddress(childOrder, shop);
    // 最后插入订单
    childOrderMapper.insert(childOrder);
    // 发送订单创建事件
    applicationEventPublisher.publishEvent(new ChildOrderCreatedEvent(this, shop, childOrder));
    return childOrder;
}

4、映射数据库的属性尽量不要用基本类型

int/long 用它的包装类型Integer，Long, 入库时没有就算null
int/long 等基本数据类型作为成员变量默认值是 0。入库时没有容易为 0
现在流行使用mybatis 等 ORM 框架，在进行插入或者更新的时候很容易会带着默认值插入更新到数据库。

5、封装判断条件

当有很多条件判断时，也尽量去封装，提升可读性

public void method(LoanAppEntity loanAppEntity, long operatorId) { 
if (LoanAppEntity.LoanAppStatus.OVERDUE != loanAppEntity.getStatus()
&& LoanAppEntity.LoanAppStatus.CURRENT != loanAppEntity.getStatus() 
&& LoanAppEntity.LoanAppStatus.GRACE_PERIOD != loanAppEntity.getStatus()) { //... return; }

这段代码的可读性很差，这 if 里面谁知道干啥的？我们用面向对象的思想去给 loanApp 这个对象里面封装个方法不就行了么？

public void method(LoanAppEntity loan, long operatorId) {
  if (!loan.finished()) {
    //...
    return;
  }

6、不要重复造轮子

利用好现有的工具类和方法，比如对集合、时间的处理，一些现有的业务方法。尽量利用现有的
不要自己写，造成重复劳动，并且多搞了很多类和方法

7、使用 @ConfigurationProperties 代替 @Value

多个类似属性使用@ConfigurationProperties 是更好的
可以注入多个属性，@Value 只能一个一个写
在项目 application.yml 配置文件中按住 ctrl + 鼠标左键点击配置属性可以快速导航到配置类。写配置时也能自动补全、联想到注释。需要额外引入一个依赖 org.springframework.boot:spring-boot-configuration-processor 。
@ConfigurationProperties 支持 NACOS 配置自动刷新，使用 @Value 需要在 BEAN 上面使用 @RefreshScope 注解才能实现自动刷新

8、写有意义的方法注释

这样的注释就不好，第一描述过于简单，其次每个参数列出来却没有说明，不如不列参数

/**
* 请求电话验证
*
* @param credentialNum
* @param callback
* @param param
* @return PhoneVerifyResult
*/

###

标签：shop,childOrder,return,自我,Long,规范,日常,封装,public
来源： https://www.cnblogs.com/cherychina/p/16054222.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9