程序员在战斗过程中应该注意点什么

前景：洪荒之后，历经亿万年的演变，猿类才进化成了人，但是才短短的半个世纪，新的一群灵长类诞生了，就像猩球崛起一样，这个群体正在改变着世界--程序猿。为了有更好的战斗素养，程序猿应该注意点什么呢？请接着往下看。

一、夯实的内功（即使没有张无忌的命也要有保尔柯察金的毅力）

1、数据结构与算法

2、设计思想

3、架构思想

4、打太极

二、缜密的心思

1、处理各种各样的 nullPointException 

①、他人的数据/接口，并不可信，使用之前先StringUtils.isNotBlank()一下，或者Collections.isEmpty()一下，或者 null ！= Obj一下，一定会避免很多坑。

②、关于String转json的时候，JSONObject或者JSONArray的转换方法可是会返回null的，不信你试试看，使用之前应该进行①的处理。

③、关于redis的list的处理，这个可是防不胜防，比如你查询一个有条件的列表要获取里边的符合ABC三个条件的数据，但是人家恰恰没有数据符合条件B，这个时候人家可是会返回这样一个结果：rA,null,rC。惊不惊喜意不意外，没有符合条件的不给我就是了，干嘛非得返回一个null呀，人家就是要占着茅坑不拉屎，可能是为了保持下标位置一一对应吧，也让你知道有哪些条件在redis中是没有符合的，所以呢，使用redis返回的list类型的数据之前需要做的操作就是移除null元素（如果有必要）:dataList.removeAll(Collections.singleton(null))。

④、为了表示负责任，我们自己写的接口的返回结果都要避免null，这个可以使用JDK8里边的Optional解决：

Optional.ofNullable(omc).map(OMCChange::getGrouptype).orElse("create");//Optional.ofNullable() 完美的避免了空指针的问题

2、恰到好处的日志打印

①、为了更快的抓住坏人，在方法的入口和出口都要打印日志，最好是入参和出参都打印一下，不过出参有时候太长了可以只打印一个长度，不能一天光日志1、2个G。

②、为了找到某个人干的所有的坏事儿，在请求过来的时候给它一个threadID，这样既可以知道这个请求在你的系统里都干了什么事儿了。

3、是时候展现真正的技术了（注释）

①、方法以及复杂逻辑的注释，切记不要拷贝注释，否则你会发现，命名是个李鬼，你却标注一个李逵，坑。

②、魔法数字的注释，或者枚举类内容的注释

③、数据库表和字段的注释（这个一定要写，否则一大堆的C1.C2.C3...谁TMD知道是啥东西）