程序员，你总要有点自己的想法吧！

程序员，你总要有点自己的想法呀！~~思维

 

 

 

个人总会倾向于认定自己的能力比较强。个人总会高估自己的能力而弱化他人的能力。

团队绩效考评，假设总分100，看团队里每个人的绩效占比。假如让每个人给自己打分，那么结果往往会超过100分。而如果让每个人给他人评分，结果总是会低于100分。

 

如下方法，返回布尔类型，你定义PsmMessageCode.TRUE和PsmMessageCode.FALSE这2个常量有毛用？

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的输入流里获取。果然如此。因为，毕竟，获取远程的请求数据也不外乎这两种方式。当然，这也依赖于对知识的系统化的积累和总结。

 

一个日终才执行的定时任务，上线日上线，运维部署到生产环境后，如果没有什么更好的验收策略，开发人员和QA就要一直死等到日终时分，观察任务执行情况，来做验证工作。碰巧就那么不巧，这个定时任务在生产环境执行时报错了。然后，一顿排查，还要劳烦运维伙伴，甚至在规范的团队里还要走申请流程。弄完后，整个人筋疲力尽！ 这种工作方式必然是要摈弃的，元芳，你有什么好办法？