我最鄙视的程序员

今天在技术群里看到关于优秀程序员特质的话题，让我想起多年前的一个同事，一个我最鄙视的程序员。

他的名字叫李伟(化名)，是入职没多久的员工，我所在的开发二组和他在的一组，以前没有过工作交集。某一天上级安排我们两组人合作开发一个小额贷款项目，在基础服务上构建一个可以灵活对接多个贷款渠道的系统。

• 渠道对接层：承接渠道的原始数据，解密并解析为我方可以处理的格式和字段。每个渠道对应一个独立的微服务，调用业务融合层的接口，完成业务流程。

• 业务融合层：处理渠道编号和订单、还款等业务映射关系。融合多个流程整合到一个接口中，对外提供标准化的接口，类似中台的概念。

一组的组长安排他做了几个重要的事情，具体是定义订单、还款等接口，调用更底层的业务接口实现自己的接口业务。我们对接流量渠道，调用他定义的接口完成业务流程。通常新人做事难免磕磕碰碰，但是项目的时间很充裕，做一些重要的事情也能更好的展示自己的水平。我认为他的组长的安排没有问题。

我们先开会学习和讨论了产品流程，目的是让每一位开发人员都知道数据结构和走向。为了确保我们的进度，我建议他先给出接口定义，再找个会议室，双方评审一下接口，确认无误后通过maven发布依赖包，这样我们就可以填充代码了。他答应了先给接口定义，但是拒绝评审接口，理由是这个东西很简单，不用大费周章。我考虑了一下，等他给出接口定义，我们认为有问题就指出来，算是非正式评审。整整过了一周，他的接口终于来了，总共4个接口，每个接口里面有6、7个方法。这个事情拖延了一周，让我有点不快了。

他给接口的方式让人耳目一新，直接把接口源文件甩了过来。公司有一套采用RAP2搭建的API管理系统，还是他们一组牵头做的。作为一个新人，应该先熟悉公司有哪些辅助开发的系统，就算同事不告诉你，也要主动问。更妙的是，他的源码一行注释也没有，好在代码的英文单词都是常见的，我们勉强能看懂。

我们内部评审之后，发现有几个方法的入参有9个之多，于是建议他封装在一个JavaBean里面。

List<LoanOrder> queryLoanOrder(String channelId, String orderId, Integer userId, Bigdecimal minAmount, Bigdecimal maxAmount, Date startTime, Date endTime, Integer pageSize, Integer pageNo);

他有些不悦，认为意义不大，缺了参数继续加就行。毕竟不是我管理的人，我不想花心思教育，只说这是公司代码规范，希望他务必改一下。他不情愿地改了入参，结果都变成了JSONObject。

List<LoanOrder> queryLoanOrder(JSONObject jsonObject);

我问他为什么要用JSONObject，得到的回复是：这样更灵活，往JSONObject里面 put key / value 就能增加参数。我直接来个灵魂三问：1. 必须要看文档才知道key是什么，value的类型是什么，而你又不给文档；2.采用不明确的入参，Hibernate Validator肯定用不了，打算怎么做参数校验；3. JSONObject有什么特别之处？用Map也是一样的。在我的拷问之下，他又屈服了，改成了JavaBean。如果他有足够的理由说服我，我倒是敬他是条汉子。

进入接口联调阶段，我们的同事事先跟他约好周二下午四点联调订单接口。到了周二下午，我们调了几次订单接口，发现返回结果不理想，把数据发给他看看。

“接口实现我还没写好呢，结果当然不正确。”
“那你为什么答应联调呢？”
“只是联调，调通了就行，为什么一定要完全正确？”
“什么时候可以完全正确呢？”
“提测之后，测试人员测出问题了，我就改改。”

我意识这个人不行，马上跟他的组长反馈了问题。再与他沟通的时候，表现的更不积极了，无论事情大小，都要一催再催。我有查阅所有相关项目代码的权限，闲来无事看了看他的代码。在一个订单接口实现里面发现这样的写法：

if(orderId == null || orderId.length == 0) {
    throws XXXX;
}

我友好的提醒了他：StringUtils的运用是基本功，这个写法可以改成StringUtils.isBlank(orderId)。

"不是一回事吗？"他淡淡的回了一句。
"代码能跑，只是底线，不是及格线"，我终于愤怒了。

后来，一组组长让他走人了，没过试用期。这是我见过基本功最差、态度最不端正的程序员。我不知道他怎么被招聘进来的，招聘流程肯定有问题，他的组长也有失职之处。