沟通理解的不易

做的东西又一次被否定，什么心情呢？一开始真是蛮无奈的感觉？交给自己的任务没有做好，会蛮失望，觉得我做事情怎么做成这个样子。一次一次没有按照别人期望的那样来完成任务？没有能心领神会别人的想法倍感愧疚呐，也让自信心收到了打击。

说说这个运费上传系统吧。

第一次的需求是Y给我说的。提出这个需求的原因是上传人员每次上传数据超过两千条系统就崩溃了。每次他们只能拆开来上传，想让我这边优化下代码。一开始是在老的系统上修改，把上传逻辑和其他逻辑分开来。从另一张表获取数据和计算数据的逻辑通过定时器来抓取。基本上搞好以后，又决定重新搭建一个小系统，来完成这个功能。

F很快搭建了一个框架，我拉下来代码在自己这边跑起来。然后开始创建表，开始做这个系统。一开始以为从原有系统上拉数据，然后把Bean直接copy过来。逻辑没有改变。L看了以后说，我们这个系统不能这么做，这样格局太小了，不单是一个运费上传的功能，既然拉出来做，就要格局做的大一些，做成一个运费汇总对比的一个系统，能让对账人员统计每一天有多少单量，揽件多少，签收多少，每个月要给别人结算多少钱。那就需要先得到订单信息，再上传。

他告诉我，订单数据从订单系统取，揽件签收信息从发运系统同步过来。我整理了一下，F说，发运系统有大部分信息，取不到的才从订单系统取。我这样子也没有想，就开始做了。F给我提供了三个接口，一个取运费订单表当天数据，一个取揽件签收时间，一个取渠道发货信息。定时去取这些信息，上传时去找相对应的信息。因为出现了之前沟通的问题，我这次把我理解的逻辑写成几点，发邮件给他们确认。他们不习惯发邮件，我跟Y确认过后又跟L确认。我跟他说了之后，他反应也很大：这个抓取数据怎么会取三次呢？两次就够了，让F一次性把数据给到你，让他放到一张表里。我去跟F讨论这个问题，他情绪更大：那你现在什么都不用做了，我帮你做好，你只管展示一下数据就行了是吧？我觉得自己也蛮委屈。后面讨论来讨论去，是把数据库合并，不要接口调来调去的。就把我的这个类放到发运系统去了，把我需要的字段给了F，他那边负责同步所有的数据，我这边负责处理上传数据。我们这边不需要自己的数据库，跟发运系统共有一个了。

这样子做好之后，上传时遇到一个问题，速度太慢，因为要查询调用好几次接口。跟L说，L说你这边又弄错了。现在数据库不是合并了吗？怎么还调用接口。我说F给我提供的这些接口，他回家那天给我的，虽然共用数据库，但还是通过接口访问。我这边的Dao，service已经删除了。L说：哎呀，调什么接口，直接访问不就行了吗？把Dao和service加上，你们就本地访问。这样又是一次大改。他看了下我的逻辑，说运费计算前面说的是你把计算方法提供给F，你这里就不需要计算。我是真的忘了这件事了。这样修改以后，整个系统才算是定下来了。

算是折腾了六次吧，大家考虑的层次方面不一样，所以实施起来思维也不一样。Y是优化功能层面，L是更高可以使用的功能层面，F比较关注技术层面，我就是跟着他们跑。L告诉我要哪些数据，去哪里取。F则提供给我去哪里取方便，快捷，合理。因为F技术牛，所以我是跟着他给到我的思路走的。到合并数据库删掉Dao，service时我都没有想到这样不合理呐。到后面遇到heap stack overflow时，才发现这样做不合理。

第一次被否定是因为我不能站在L的业务角度去考虑问题，把这个系统的格局做大一些；Y则站在业务需求的角度，优化一下。第二次则是取数据时跟着F能提供给我的思路走，F觉得这样分开存放数据，订单物流一个表，揽件信息一个表，签收一个表，查询数据时方便快捷，L则觉得这样调用太麻烦，希望数据都在一张表里，好调用。第三次则是数据库合并后用接口的问题。F给我提供接口我就用接口调用，L想的是直接操作数据库。

中间我们沟通理解的误差有很大吗？好像也没有，但是就是细微想法上的差异，出现了失之毫厘谬以千里的情况。能让想法很好的实现，需要几个人能在知识等方面储备差不多，或是能发现没有详细讨论细节中的遗漏，有发现问题的能力。沟通能力确实是件不容易的事。要能跟别人愉快的沟通到一起真是不容易呐。