前言 接口性能优化对于从事后端开发的同学来说，肯定再熟悉不过了，因为它是一个跟开发语言无关的公共问题。 该问题说简单也简单，说复杂也复杂。 有时候，只需加个索引就能解决问题。 有时候，需要做代码重构。

最近发现团队有些新人有个坏毛病，就是 git 提交信息全是 ok，用 sourcetree 一看，整整齐齐全是 ok，压根都不知道每次提交解决了什么问题。 在一个团队当中，既然大家维护同一个仓库，就要遵循相应工作流程和提交规范，其中 commit message 是比较重要的一…

最近公司貌似融到资了！开始发了疯似的找渠道推广，现在终于明白为啥前一段大肆的招人了，原来是在下一盘大棋，对员工总的来看是个好事，或许是时候该跟boss提一提涨工资的话题了。 不过，涨工资还没下文，随之而来的却是一车一车的需求，每天都有新渠道接入，而且每个渠道都要提供个性化支持，…

昨天早上通过远程的方式 review 了两名新来同事的代码，大部分代码都写得很漂亮，严谨的同时注释也很到位，这令我非常满意。但当我看到他们当中有一个人写的 switch 语句时，还是忍不住破口大骂：“我擦，小王，你丫写的 switch 语句也太老土了吧！” 来看看小王写的代码吧…

所以接下来落实到代码上，举个通俗一点的小例子唠一唠，实际业务代码虽然比这个复杂，但原理是一模一样的。 假如哪一天程序羊真发达了，一口豪气买了两辆豪车，一辆五菱宏光、一辆飞度、并且还专门聘请了一位驾驶员来帮助驾驶。 这暂且看起来没问题！日子过得很融洽。 很容易想到，我们应该做一层…

特别是遍历过程中使用，需要判断是否为空。

我自己曾经接手过一个前人留下来的老项目，拿到代码，导入IDEA的那一刻，我哭出了声。 别的咱先不说，居然明目张胆地在Controller层里方法里用Map传参？！简直丧心病狂了。幸亏下面还有一波传参有效性的验证，对于传递的参数，我好歹也能猜个大概，不然那真是喵了个咪了。 正好，…

先说一下具体的需求：公司推广入口很多，每一个下单来源在下单时都做特殊的逻辑处理，可能每两天就会加一个来源。 为什么非得写的这么臃肿？很多同事会说：“哎呀，没办法呀，业务催的紧，这样开发效率快省事”。的确是句大实话，很多时候业务方确实像催命鬼一样的让你赶工期，想快速实现功能，这样…

我们经常使用一些sdk来完成我们的需求，但往往有些sdk对外暴露的接口并不合理，再加上如果这个sdk本身处于快速迭代期，每次变更某些api的话，业务方如果使用的地方较多，那么批量修改 其实也是比较麻烦的。 问题就是这个sdk对外提供的函数参数过多，没有封装性，且可以很容易想到日…