程序员，你总要有点自己的想法呀！~~思维
个人总会倾向于认定自己的能力比较强。个人总会高估自己的能力而弱化他人的能力。
团队绩效考评，假设总分100，看团队里每个人的绩效占比。如果让每个人给自己打分，那么结果往往会超过100。而如果让每个人给他人评分，结果总是会低于100。
如下方法，返回布尔类型，PsmMessageCode.TRUE和PsmMessageCode.FALSE定义这些有毛用？
public boolean updateByPrimaryKey(PsmOrdDO psmOrdDO) { int red = psmOrdDOMapper.updateByPrimaryKey(psmOrdDO); return red > 0 ? PsmMessageCode.TRUE : PsmMessageCode.FALSE; }
如下方法的作用是持久化记录，最终仅仅返回是否持久化成功。对于这种情况，你直接返回boolean就行了，省去了别人了解BasicRspCO和ReturnUtils的时间。我们要做的，是把复杂事情简单化，而不是简单事情复杂化。切勿本末倒置！ 我问过写这段代码的当事人，得到的答复是看别人是这么写的，然后自己也这么写。还信誓旦旦的地说“是为了统一”。中毒很深啊！任何开发团队，代码规范，都不能也不会主张这种统一。
public BasicRspCO updateByPrimaryKey(PsmOrdDO psmOrdDO) { 。。。 int red = psmOrdDOMapper.updateByPrimaryKey(psmOrdDO); return red > 0 ? ReturnUtils.returnSuccess() : ReturnUtils.returnFail(); }
话说：好的可以模仿，不好的，就别模仿了。
这涉及到很重要的一点，你得有意识地去琢磨哪些不好。很多程序员，水金火木土都不缺，唯独缺这个意识，就剩下一味的模仿了。
认知的4种境界：
- 不知道自己不知道
- 知道自己不知道
- 知道自己知道
- 不知道自己知道
关于数据类型，比如数据表字段，有些程序员习惯把多数字段定义成varchar。比如日期，比如表示是否的字段。如果没有特殊的用意，从程序可读性来说，还是定义成明确的类型更合理。
关于枚举定义。当一个词汇的值在有穷序列里变动时，可以定义成枚举，提高程序可读性。而诸如“是否审核成功”这样的，定义枚举就显得多此一举了，直接用布尔取代即可。同样，像性别，如果系统对此无过多需求，就干脆也定义成布尔。微博/空间/社区系统另说。这涉及到领域知识了。就像地址，对于支付系统来说，定义一个属性就够了，而对于电商物流系统，就要细化到街区、具体地址等数个属性了。
一个定时执行的同步商旅机票订单的ETL程序，因为赶工期，我告诉开发人员对性能要求不高。提测后发现，程序执行耗时长达20分钟。哥们的实现亮瞎了我的24K钛合金狗眼：每从数据源取到1000条订单记录后，由于要给每条订单匹配舱位、城市、机场、预定员工等信息，他在遍历集合的循环里，直接把这些基础表的全量数据都从db读出来，然后在内存用linq进行过滤。——纵然对性能要求不高，但总不能这么随意呀？！ ——后来通过调整程序，把从db获取基础表全量数据提到循环之前，性能才恢复到正常的10秒±。
用户的一次扫码支付，上游渠道处理完成后会主动将支付结果通知给我方系统。调试接口时，同事试图通过历往经验从request.getParameterMap()获取，可是通过log发现，并无卵用。开始各种怀疑。看他在纠结这个问题，我提议，是不是可以从request的输入流里获取。果然如此。因为，毕竟，获取远程的请求数据也不外乎这两种方式。当然，这也依赖于对知识的系统化的积累和总结。
一个定时任务，测试环境测试通过了。上线部署到生产后，由于没到触发的时间点，没有执行。许多任务都是日终才执行。这时，开发人员可能已经回家了，可能还在默默地值守等待。碰巧就那么不巧，这个定时任务在生产环境执行时报错了。然后，一顿排查，还要劳烦运维伙伴，甚至在规范的团队里还要走申请流程。弄完后，整个人筋疲力尽！ 这种工作方式必然是要摈弃的，元芳，你有什么好办法？