当你换槽填坑时，面对一个新的环境。能够快速熟练，上手实现业务需求是关键。
但是，哪些因素会影响你快速上手呢？是原有代码写的不够好？还是注释写的不够好？
昨夜，闲情雅致，瞅了瞅隔壁小王的代码，看完之后真是太上火，气不打一处来。
于是，把小王犯的错误拉了个清单，一起帮他改进一下，顺便看看这些坏习惯，你是否也有呢？
1.
过度相信别人，会给自己挖坑。
针对接口输入参数，没有进行严格校验，尤其是要插入数据库库的参数，一路透传到底（数据库层面），数据库就报数据插入异常。
对于调用者而言，会一直等待接口响应，而最后拿到数据库错误，会一脸懵 B；对于接口本身而言，会占用数据库连接，损耗资源，如果并发量大的情况，影响可想而知。
建议：业务代码研发过程中，不要相信调用者会按照要求传参数，要做到防御性编程。
2.
异常捉都捉啦，就差一哆嗦。
2.1. 抓住了异常，却什么都没做！
2.2. 打印异常栈的方式，却显得毫无意义。
估计很多人，都会这么写，但是在生产上，却显得意义不大，所以最好用记录日志的形式输出异常信息。
建议：业务代码研发过程中，针对接口中发生的异常，既然进行了 catch，那就一定要好好封装处理，若不做任何处理，私自把异常给吞没了，一旦线上出了问题，却不知道问题出在了哪里。
3.
小儿科的问题，会大意失荆州。
3.1. 代码这么写，还谈什么用户体验？
例如，用户绑定银行卡场景，判断银行卡是否已经绑定，未绑定则进行绑定。
循环遍历用户绑定的银行卡列表，然后比较传入的卡号（cardNo）是否已经绑定过，当传入的卡号与绑定的卡号一致时，修改 hasCard 为 true，并没有跳出循环，继续下一次比较判断。
那么，如果类似这种代码，发生在数据量比较大的场景下，势必会降低性能，过度浪费资源，用户肯定会骂街。
建议修改方式（仁者见仁智者见智）：
3.2. 数据挨个去处理，怎么还出现了漏网之鱼？
例如，三方数据对账时，判断三方传过来的数据在本地状态是否正常匹配，把没匹配的数据进行注销处理。
代码这么写，一旦条件匹配，进行删除某条记录后，list 的大小发生了变化，而 i 的值也在变化，就会导致在遍历的时候，漏掉某些记录。
比如，当删除第 1 个元素后，继续根据索引访问第 2 个元素时，因为删除的关系，后面的元素都往前移动了一位，所以实际访问的是第 3 个元素。
建议采用 Iterator 删除，或者集合倒序遍历删除。
3.3. & 与 && 的使用不当，终酿错。
例如，在 Web 项目中，判断输入的邮箱是否为空。
当 email 输入为 null 时，& 使用时，后面的条件会发生空指针异常。
建议修改为:
同样，| 与 || 也有类似的情况，所以在使用时，也要注意此类场景的问题。
3.4. equals 比较，搞不好会出幺蛾子。
当 resMap.get(Global.RETCODE) 为 null 时，会发生空指针异常。
鉴于 Object 的 equals 方法容易抛空指针异常，所以业务研发中，应使用常量或确定有值的对象来调用 equals。
建议修改为：
3.5. 数学运算，搞不好会倾家荡产。
输出结果：0.010000000000005116，一般遇到需要用到浮点数运算的地方，都可以使用 java.math.BigDecimal。
建议修改为：
注意构造 BigDecimal 的参数为 String，千万别搞错了，这也是新手易犯的问题。
3.6. 奇葩的注释，看到就想骂街。
3.6.1. 项目中的某类的注释。
代码的作者是管理员，敢问，管理员 TM 又是谁？而且源文件有过修改，但是修改描述的是啥？着实让人费解！
3.6.2. 项目中的某方法的注释。
方法参数没有解释；方法返回值没有解释；作者又是属于管理员；修改描述描述的是个啥？
4.
让代码会说话。
4.1. 避免江边卖水。
4.1.1. 业务接口验签代码片段。
红色圈住部分，感觉有点江边卖水，多此一举。那么，可以去掉 false 判断，建议修改如下：
同样的，代码研发中，true 的判断也一样可以去掉。
4.1.2. 用户登录代码片段。
最后的 else 有点多此一举，可以省略，可以修改为：
4.1.3. 用户是否绑定银行卡片段。
在 return 前的判断，貌似略显多余，可以修改为：
4.2. 减少 Bug，减少圈的复杂度。
(图片来源于网络)
会发现嵌套层数越多，代码越复杂，其圈复杂度也就可能越高。不过，控制嵌套层数，便是降低 Bug 发生概率的一个有效手段。
例如，下面的代码片段，项目中可谓是一抓一大把。
根据场景，可以适当调整如下：
4.3. 统一作战，代码未动，规范先行。
为了让写出的代码能够清晰阅读，前提是团队要进行统一，不能为了个人嗜好，而独创研发秘笈。
敢问，有哪些需要进行统一呢？
统一的开发环境（JDK版本、集成开发工具 IDE、存放目录...）；
统一的开发框架，更多精力集中到业务开发上；
统一的开发模板，开发工具要进行统一 Scheme；
统一的开发规约，命名、注释、代码结构等约束；
统一的 DB 规约，具备一个良好的标准。
统一的 ... ...
5.
代码评审的过程，会让人哭笑不得！
铁打的营盘流水的码农，你的代码迟早会被其他同事接手，为了让接手你代码的同事，心里不默默骂你，建议还是好好对待编码这件事，认真写好每行代码。
写代码是一件快乐的事情，评审代码更是一件有趣的事情，通过评审代码，能够相互学习，并使代码更加健壮，提早发现 Bug，所以每一次都不要错过。
最后，本次分享就到这里，希望你们能够喜欢。