⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://zhuanlan.zhihu.com/p/28708259 「晓风轻」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

工作中，少不了要定义各种接口，系统集成要定义接口，前后台掉调用也要定义接口。接口定义一定程度上能反应程序员的编程功底。列举一下工作中我发现大家容易出现的问题：

1. 返回格式不统一

同一个接口，有时候返回数组，有时候返回单个；成功的时候返回对象，失败的时候返回错误信息字符串。工作中有个系统集成就是这样定义的接口，真是辣眼睛。这个对应代码上，返回的类型是map，json，object，都是不应该的。实际工作中，我们会定义一个统一的格式，就是ResultBean，分页的有另外一个PageResultBean

错误范例：

//返回map可读性不好，尽量不要
　＠PostMapping("/delete")
 public Map<String, Object> delete(long id, String lang) {

 }

 // 成功返回boolean，失败返回string，大忌
 ＠PostMapping("/delete")
 public Object delete(long id, String lang) {
   try {
     boolean result = configService.delete(id, local);
     return result;
   } catch (Exception e) {
     log.error(e);
     return e.toString();
   }
 }

2. 没有考虑失败情况

一开始只考虑成功场景，等后面测试发现有错误情况，怎么办，改接口呗，前后台都改，劳民伤财无用功。

错误范例：

//不返回任何数据，没有考虑失败场景，容易返工
　＠PostMapping("/update")
 public void update(long id, xxx) {

 }

3. 出现和业务无关的输入参数

如lang语言，当前用户信息都不应该出现参数里面，应该从当前会话里面获取。后面讲ThreadLocal会说到怎么样去掉。除了代码可读性不好问题外，尤其是参数出现当前用户信息的，这是个严重问题。

错误范例：

// （当前用户删除数据）参数出现lang和userid，尤其是userid，大忌
　＠PostMapping("/delete")
 public Map<String, Object> delete(long id, String lang, String userId) {

 }

4. 出现复杂的输入参数

一般情况下，不允许出现例如json字符串这样的参数，这种参数可读性极差。应该定义对应的bean。

错误范例：

// 参数出现json格式，可读性不好，代码也难看
　＠PostMapping("/update")
 public Map<String, Object> update(long id, String jsonStr) {

 }

5. 没有返回应该返回的数据

例如，新增接口一般情况下应该返回新对象的id标识，这需要编程经验。新手定义的时候因为前台没有用就不返回数据或者只返回true，这都是不恰当的。别人要不要是别人的事情，你该返回的还是应该返回。

错误范例：

// 约定俗成，新建应该返回新对象的信息，只返回boolean容易导致返工
　＠PostMapping("/add")
 public boolean add(xxx) {
   //xxx
   return configService.add();
 }

很多人看了我的这篇文章程序员你为什么这么累？，都觉得里面的技术也很简单，没有什么特别的地方，但是，实现这个代码框架之前，就是要你的接口的统一的格式ResultBean，aop才好做。有些人误解了，我那篇文章说的都不是技术，重点说的是编码习惯工作方式，如果你重点还是放在什么技术上，那我也帮不了你了。同样，如果我后面的关于习惯和规范的帖子，你重点还是放在技术上的话，那是丢了西瓜捡芝麻，有很多贴还是没有任何技术点呢。

附上ResultBean，没有任何技术含量：

＠Data
public class ResultBean<T> implements Serializable {

  private static final long serialVersionUID = 1L;

  public static final int SUCCESS = 0;

  public static final int FAIL = 1;

  public static final int NO_PERMISSION = 2;

  private String msg = "success";

  private int code = SUCCESS;

  private T data;

  public ResultBean() {
    super();
  }

  public ResultBean(T data) {
    super();
    this.data = data;
  }

  public ResultBean(Throwable e) {
    super();
    this.msg = e.toString();
    this.code = FAIL ;
  }
}

统一的接口规范，能帮忙规避很多无用的返工修改和可能出现的问题。能使代码可读性更加好，利于进行aop和自动化测试这些额外工作。大家一定要重视。

芋道源码 —— 纯源码解析博客

这是我见过写得最烂的Controller层代码，没有之一！

1. 返回格式不统一

2. 没有考虑失败情况

3. 出现和业务无关的输入参数

4. 出现复杂的输入参数

5. 没有返回应该返回的数据