【开发故事】如何不被同期入职的同事甩下太多？

今天讲一个小故事，是关于同期入职的程序员小A和小D，如有雷同，纯属碰巧。
上个星期小A提了离职，项目组的Leader老L没有挽留，痛快的签了名。
小A很不服气，在外面大声吐槽，说老L两年来给工作经验差不多的小D提薪了三次，他却还是原地踏步，还说找到了新的下家，比这边的福利待遇都要更好。
老L听说后叹了口气，把小A叫进了办公室，给小A指出了他和小D的6个区别，把小A说得哑口无言。

1. 代码质量

老L打开了项目组的bug管理平台，只见小A的项目一片飘红。代码发送请求后返回结果出现错误，虽然对其他人来说也不算罕见，但是引发这些错误的入参不算极端值也不是什么奇怪的边界条件，全是正常的业务参数。
这说明什么？说明小A没写测试代码，不做测试。
再看小D的项目，基本全是绿色的已通过。打开git一看，小D的单元测试代码甚至远远超出了项目内容代码。

2. 开发速度

老L看小A还是有点不服气，又打开了开发时间统计。可以清楚看到，小D的项目平均开发时间和二次改动时间都比小A要少。
究其原因，就是小A写代码特别不灵活，有点变更就需要大改，并且还经常改出bug。而小D从来都是把方案想透彻了才开始写，还不断的重构代码，最终的代码灵活又优雅，有需求变更了，很快速就可以完成。

3. 思维方式

小A开始沉默了，老L看了一眼就继续说了下去。
有一次，小A写一个对外接口，写完了拿出去测试，结果闹了个大笑话。他写的对外接口，连个验证签名也没有。这事儿幸亏在内部测试的时候被查了出来，不然直接放出去，整个团队的专业性都要受到质疑。
而小D同样写一个接口，不仅考虑到了验证签名问题，他还考虑到了参数需要加一个时间戳，保证签名不会被重复利用。

4. 业务理解

老L既然说开了也不给小A留情面了，又说到了业务理解。
不管是例行的还是某项目的需求会，小A基本就没认真参与过，表达自己的想法，私底下也很少去和产品经理主动沟通分析需求。等到开始写代码了，要么实现出现偏差，要么出现了遗漏。
有个权限管理的需求，老L本来想给小A个机会，所以让他负责。
结果呢？权限配置甚至连个后台都没有，业务都没地方配置权限。就这样，小A还非说功能实现完了，还和产品们吵了起来，最后被啪啪打脸。人家产品的原型图和需求文档说得明明白白，还连续开了好几次需求分析会，其他人都理解了，就小A出现了问题。
后面老L安排了小D接手。小D画了角色和权限的关系图，然后每一个点都和产品过了一遍，大家都确认后，发邮件形成共识，最后开发，结果也是一切顺利。

5. 工作态度

要知道，产品经理也是普通人，自然也有想不到的地方。一般来说，小D和产品配合，偶尔出现产品经理漏掉的地方，小D都会积极去沟通，查漏补缺。但是，到小A这里，事情往往推不下去。
曾经有个功能，产品经理给的需求是：在商户信息出现变动的时候，能通知到公司其他部门的系统，其中需要对接别组负责的公共消息系统。
分派给小A，小A以“对接很麻烦，对方不配合”为借口，拖了很久没动静，气的产品经理直接找到老L告状。
把事儿交给小D后，小D先是和产品经理私底下聊了一下，然后开会协调了一个新的上线时间，把对接公共消息系统的分解需求也进行了排期。后面甚至为了快速跟进，把工位临时搬到了隔壁组在那就地开发，最后按期交付。

6. 团队意识

最后老L打开他们项目的 Git公共工具类，只见小A的提交记录是一篇空白，随意打开一部分代码，那么多可以共用的代码，小A从来没有想过提出来形成工具去方便别人。只管着自己的那摊子事儿，写完完事儿。什么代码风格、复用、团队合作全部扔在了一边儿。
而小D不一样，不但会主动写一些工具类，有时候还会弄出一些小框架，又或者像上次那样推了个Eolinker接口管理和开发工具，减少别人的开发量。

小A被怼得哑口无言，但还是隐隐有点不服气，老L也突然没了继续说下去的兴致，挥挥手让小A出去，长叹了一口气，准备继续招人了。