后端开发总结（3）：代码健壮性：容错处理+测试

1.1 客户端接收云端请求容错处理

几种错误情况

• 没有请求通，没有返回。服务端错误，对应的就是http 的状态码，比如500
• 请求通了，但是结果有问题。自定义的返回response中的code信息，比如5000

response, err := http请求
if err != nil || response.StatusCode() != http.StatusOK {
    // 打印日志信息
    log.Log().Errorf("service return configure error: %v", err)
    // 错误处理
} else {
    
    if responseBody.Code != cloud.OK {
        // 错误处理
    }
}
1
2
3
4
5
6
7
8
9
10
11

1.2 参数校验

首先明确，只要有参数就必须进行参数校验，保证代码的健壮性

服务端模型：

• 一般会在最先进入controller层和app_service层时进行参数校验，然后才是代码逻辑
• 一般到service层repo层就默认参数没有问题

自定义的方法：

• 传递的参数，必须进行参数校验，因为你不知道别人会如何进行调用。具体可以参考各种go的包提供的方法对参数的容错处理

1.3 测试

一个开发迭代下来感受自己的开发过程

• 需求分析，大概有个主线思路
• 方案初步设计，数据库设计
• 先开始写，写的过程不断修改最初的方案设计
• 发现需求细节不明确，去跟业务人员确认
• 确认好几次终于写完所有逻辑
• 发现逻辑的细节、可能的情况不是很清楚，继续确认
• 运行起来测试一下，不工作，调试
• 测试，调试好久终于工作了
• 终于，代码可以工作了，一看代码烂的像坨屎
• 实际上线使用，又发现一堆新的bug，逻辑漏洞、没有涵盖的数据情况、代码bug，不断迭代修复…

总结：

• 思路梳理不清楚、细节不完善，写的时候漏掉很多情况，代码实现后面就变成了修修补补
• 代码框架：日志打印+参数校验+容错处理+数据转化+总体逻辑
• 代码简洁性
  • go文件放在哪个文件夹下面才能很好的保证整体结构
  • 代码调用，什么时候需要抽象出新的方法，使代码不会臃肿冗余，抽象出的代码应该放在哪里
  • 代码自身的实现，简洁性，代码简洁之道
  • 代码涉及的设计模式、比如什么时候用类方法，什么时候只是一个方法，什么时候用dao，option，condition
• 建议学习数据库开发经验

优秀的测试可学习：

DDD测试驱动开发