程序员你为何这么累？

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

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

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

你们写的东西都是一些crud的业务逻辑代码，为何你们这么累，加班加点每天都是奋斗者？我从本身带的项目中观察中发现，大部分人的大部分时间都是在 定位问题 + 改代码，真正开发的时间并很少。定位问题包括开发转测试的时候发现问题和上线后发现问题，改代码的包括改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代码，虽然我比较严厉，可是仍是愿意待在我项目组，毕竟加班比其余项目组少啊。

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

1. 接口定义规范 点击阅读
2. controller规范 点击阅读（ResultBean的格式和缘由请看这里）
3. 日志规范 点击阅读
4. 异常处理规范 点击阅读
5. 国际化j和参数校验规范 点击阅读
6. 工具类规范
7. 函数编写建议 点击阅读
8. 配置建议 点击阅读

 

这些规范不是网上的哪些编程规范，说实话哪些又长又繁琐，实践中证实很难落地，我这里的规范都比较少，一针见血，你看了便知。敬请期待！

 

====================GITHUB地址======================

全部的代码细节都在已经上了github了，地址 xwjie/PLMCodeTemplate，欢迎加星。有问题欢迎提出。

 

我后面帖子都会收录到专栏 个人java学习之路及习惯，请你们关注，谢谢！