程序员你为何这么累 | 编码规范

导读

你们一提到程序员，首先想到的是如下标签：苦逼，加班，熬夜通宵。可是，但凡工做了的同窗都知道，其实大部分程序员作的事情都很简单，代码 CRUD 能够说毫无技术含量，就算什么不懂依葫芦画瓢不少功能也能勉强作出来，作个多线程并发就算高科技了，程序员这行的门槛其实仍是比较低的。（这里说的是大部分，有些牛逼的，写算法、jvm 等的请自动跳过）

是否是以为很矛盾，一方面工做不复杂，一方面却累成狗。有没有想过问题出在哪里？有没有想过期间都花在哪里呢？

对于我我的来讲，编码仍是一个相对轻松的活（我是负责公司it系统的，没有太多技术含量，数据量大，但并发量不大）。从工做到如今，我加班编码的时间仍是比较少的，我到如今为止天天还会编码，不多由于编码工做加班。

你们写的东西都是一些 CURD 的业务逻辑代码，为何你们这么累，加班加点每天都是奋斗者？我从本身带的项目中观察中发现，大部分人的大部分时间都是在 定位问题 + 改代码，真正开发的时间并很少。定位问题包括开发转测试的时候发现问题和上线后发现问题，改代码的包括改 bug 和由于需求变更修改代码（后面专门开一贴说如何应对需求改动）。

因此说，simple is not easy。不少人就是由于以为简单，因此功能完成本身测试 ok 了就算了，没有思考有没有更加好的方式。归根究竟是由于编码习惯太糟糕，写的代码太烂，致使没法定位频繁修改频繁出问题。（后面我会详细讲一些我看到的大部分的编码问题。）

其实，对于我的来讲，技术很重要，可是对于工做来讲，编码的习惯比技术更加主要。工做中你面试的大部分技术都不须要用到的。工做中，由于你的编码习惯很差，写的代码质量差，代码冗余重复多，不少无关的代码和业务代码搅在一块儿，致使了你疲于奔命应付各类问题。

因此我做为 SE，无论接手任何项目组，第一步就是制定代码框架，制定项目组的开发规范，把代码量减下去。事实上证实，这一步以后，你们的代码量能下去最少1/3，后台的问题数降低比较明显，你们的加班会比以前少。

给你们一个直观的例子。下面是 controller 的一个删除数据的接口，我来以前你们写的这个样子的（其实一开始比这个还差不少），功能很简单，输入一个对象id执行删除返回是否删除成功。你们有没有以为有什么问题？

@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang) {
  Map<String, Object> data = new HashMap<String, Object>();

  boolean result = false;
  try {
    // 语言（中英文提示不一样）
    Locale local = "zh".equalsIgnoreCase(lang) ? Locale.CHINESE : Locale.ENGLISH;

    result = configService.delete(id, local);

    data.put("code", 0);

  } catch (CheckException e) {
    // 参数等校验出错，这类异常属于已知异常，不须要打印堆栈，返回码为-1
    data.put("code", -1);
    data.put("msg", e.getMessage());
  } catch (Exception e) {
    // 其余未知异常，须要打印堆栈分析用，返回码为99
    log.error(e);

    data.put("code", 99);
    data.put("msg", e.toString());
  }

  data.put("result", result);

  return data;
}

其实上面的代码也没有大问题。而我接手以后，我会开发本身的代码框架，最后制定代码框架交付的代码以下（这是 controller 的部分）:

@PostMapping("/delete")
public ResultBean<Boolean> delete(long id) {
  return new ResultBean<Boolean>(configService.delete(id));
}

用到的技术就是 AOP，也不是什么高深技术。怎么样？代码量就一行，特性一个都没有丢。这就是咱们项目组如今的 controller 的样子！（若是刚好有我带过的项目组的人，看到 ResultBean<> 应该很熟悉应该知道我是谁了）

因此说技术无所谓高低，看你怎么样用。上面的代码简单说一下问题，第一，lang 和业务没有什么关系，我后面的代码框架去掉了（不是说我后面的代码没有这个功能，是把他隐藏起来对开发人员透明了，使用的技术就是 ThreadLocal ）。第二，前面那个代码，实际上干活的就只有一行，其余都和业务代码没有一毛钱关系，个人代码框架里面彻底看不到了。

使用的技术真的很简单，可是编码效果很是好，由于你们不要由于使用的技术初级就以为不重要！！使用这套框架后，你们不再须要大部分时间都写一些无聊的代码，能够有更加多时间学习其余技术。说实话，在我项目组的开发人员都是比较幸运的，以为能学到东西，不是像其余项目组，写了几年都是同样的 CRUD 代码，虽然我比较严厉，可是仍是愿意待在我项目组，毕竟加班比其余项目组少啊。

这就是我说的工做中，编码习惯（或者说编码风格）比技术更加剧要。我工做了也有很长时间了，我以为我我的价值最大的地方就是这些，技术上其实我懂的也和你们差很少，但编码上我仍是以为能够超过大部分人的。后面我会把咱们这些业务系统中你们编码的问题一个一个写出来，并把个人解决办法分享出来。谢谢你们关注！

接口定义常见问题

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

返回格式不统一

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

错误范例
返回 map 可读性很差，不知道里面是什么

@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang) {

}

错误范例
返回 map 可读性很差，不知道里面是什么

@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();
  }
}

没有考虑失败状况

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

错误范例
不返回任何数据，没有考虑失败场景，容易返工

@PostMapping("/update")
public void update(long id, xxx) {

}

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

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

错误范例
（当前用户删除数据）参数出现lang和userid，尤为是userid，大忌

@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang, String userId) {

}

出现复杂的参数

通常状况下，不容许出现例如 json 字符串这样的参数，这种参数可读性极差。应该定义对应的 bean。

错误范例
参数出现json格式，可读性很差，代码也难看

@PostMapping("/update")
public Map<String, Object> update(long id, String jsonStr) {

}

没有返回应该返回的数据

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

错误范例
约定俗成，新建应该返回新对象的信息(对象或者 ID )，只返回 boolean 容易致使返工

@PostMapping("/add")
public boolean add(xxx) {
  //xxx
  return configService.add();
}

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

总结

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

Controller规范

第一篇文章中，我贴了2段代码，第一个是原生态的，第2段是我指定了接口定义规范，使用AOP技术以后最终交付的代码，从15行到1行，本身感觉一下。今天来讲说你们关注的AOP如何实现。

先说说Controller规范，主要的内容是就是接口定义里面的内容，你只要遵循里面的规范，controller就问题不大，除了这些，还有另外的几点.。

统一返回ResultBean对象

全部函数返回统一的 ResultBean/PageResultBean 格式，缘由见个人接口定义这个贴。没有统一格式，AOP 没法玩，更加剧要的是前台代码很很差写。固然类名你能够按照本身喜爱随便定义，如就叫Result。

你们都知道，前台代码很难写好作到重用，而咱们返回相同数据结构后，前台代码能够这样写（方法 handlerResult 的重用）：

// 查询全部配置项记录
function fetchAllConfigs() {
  $.getJSON('config/all', function(result) {
    handlerResult(result, renderConfigs);
  });
}

// 根据id删除配置项
function deleteConfig(id) {
  $.post('config/delete', {
    id : id
  }, function(result) {
    console.log('delete result', result);
    handlerResult(result, fetchAllConfigs);
  });
}

/**
  * 后台返回相同的数据结构，前台的代码才好写才能重用
  * @param result： ajax返回的结果
  * @param fn： 成功的处理函数（传入data）
  */
function handlerResult(result, fn) {
  // 成功执行操做，失败提示缘由
  if (result.code == 0) {
    fn(result.data);
  }
  // 没有登录异常，重定向到登录页面
  else if (result.code == -1) {
    showError("没有登陆");
  }
  // 参数校验出错，直接提示
  else if (result.code == 1) {
    showError(result.msg);
  }
  // 没有权限，显示申请权限电子流
  else if (result.code == 2) {
    showError("没有权限");  
  } else {
    // 不该该出现的异常，应该重点关注
    showError(result.msg);
  }
}

ResultBean不容许日后传

ResultBean/PageResultBean是controller专用的，不容许日后传！往其余地方传以后，可读性立马降低，和传map，json好不了多少。

Controller只作参数格式的转换

Controller作参数格式的转换，不容许把json，map这类对象传到services去，也不容许services返回json、map。写过代码都知道，map，json这种格式灵活，可是可读性差（ 编码一时爽，重构火葬场）。若是放业务数据，每次阅读起来都十分困难，须要从头至尾看完才知道里面有什么，是什么格式。定义一个bean看着工做量多了，但代码清晰多了。

参数不容许出现Request，Response 这些对象

和json/map同样，主要是可读性差的问题。通常状况下不容许出现这些参数，除非要操做流。

不须要打印日志

日志在AOP里面会打印，并且个人建议是大部分日志在Services这层打印。

建议

Contorller只作参数格式转换，若是没有参数须要转换的，那么就一行代码。日志/参数校验/权限判断建议放到service里面，毕竟controller基本没法重用，而service重用较多。而咱们的单元测试也不须要测试controller，直接测试service便可。

规范里面大部分是 不要作的项多，要作的比较少，落地比较容易。

原文：xwjie