以理服人方法三正一反

三正

1>类比业界公认的优秀开源代码实践

2>逻辑分析

3>不要假定要证明

一反

断章取义

类比业界公认的优秀开源代码实践

前段时间下架的某令上有段对话：

温：而今有我在你身边，任凭你的仇家是天王老子、神仙鬼怪，我也能……

周：怎么？你还有见神杀神见佛杀佛的本领。

温：哎~，罪过罪过。我温某人心系天下苍生，怎会乱造杀孽。我要说的是任凭你的仇家是谁来了，我也能以德服人。一通引经据典、天花乱坠，说的他是戾气尽消，放下屠刀。

引经据典也是我与人沟通时管用的方式：“你的代码写的没错，但是这样这样写会更好些，这也是spring源码里常用的手法，一会儿我回到工位把spring源码用到的地方给你发过来。”

也有引经据典解决不了的问题。毕竟在《批判性思维》里就有提到：听信专家经验是判定真理时的谬误。

逻辑分析

来看一下下面这个场景：

逻辑上就是业务系统一个服务，这里称作服务A；数据处理一个服务，这里称作服务B。一个功能比方说是返回《红楼梦》的一段简介。A自身可以获取到红楼梦的描述，但是人物列表要从B获取。就是需要A调用B。

要做什么我说清楚了没？没清楚就多多包涵吧。

负责B服务的同事根据之前的了解是这个人物列表没有顺序，用一个HashSet来存储即可。我作为A服务的开发者，当时建议同事直接把B服务的这个接口返回Set。我说不关心这个是HashSet还是别的Set。现在返回抽象不返回具体也是一个最佳实践。咱们自己写代码也是Map map = new HashMap; Set set = new HashSet()。这样实现类有了变动，对这个接口的调用方也无需修改。可维护性更强。

同事说我当然要关心啦，需求要求接口返回是无序的，我不把接口定义成HashSet，我怎么告诉你是有序的无序的呢？

因为这是一个很重要的需求，因为不管返回是什么，最终对这个需求来说都能保证正确性，我就没有较真。因为我意识到我们的分歧在于对领域划分的认识，这个解释起来会需要一些时间。关键是我当时也没有组织好语言。

过了几个小时，产品重新梳理后把需求改了。要返回一个有序的Set。这个顺序要按照手动调整顺序来排序。说把林黛玉放到前面，就把林黛玉放到前面这个样子。由于同事非要把接口改成TreeSet。他自己也是要麻烦些重新打包上传。他改了接口，但是没有改snapshot包的版本，拉取最新版本很费劲，我根本没有拉取到。提交到代码库中的代码本来好好的代码编译报错了。原来，不管同事怎么返回，我获取的都是直接用Set。并不影响我的运行时代码。但是我的单测报错了。之前传入Set set = new HashSet。但是接口的返回类型变了，不兼容了。简而言之，维护性不好是毋庸置疑的。但是这是好不好的问题，同事的点在于对不对。对错必然是凌驾于好坏之上的，我用这个论点没有说服力。

接口不兼容是代码设计的大忌。我要是用这个理由来说服他，我自己都能想到他怎么回答我：这不是没上线嘛，上线达成release包后，我再修改的话，就新添加一个方法就好了呀？

这么看来，从领域上来说：A负责组装，B负责一部分基础数据。这是最基础的按照角色划分领域。

按照同事的理解，产品最终是A输出的，产品要求最后输入人物列表是有序的。那A就应该判断是不是符合要求的。其实不是这样的，正确的理解是A服务和B服务共同组成了整个系统，这个系统输出的产品是有序的。A和B要各司其职。B负责人物列表，它就做出符合产品要求的人物列表，然后告诉A人物列表做好了。产品需求的细节：有序、人物名称不允许有特殊字符、人物只包含金陵十三钗还是所有有名有姓的都包含……这些细节自己处理好。A只是负责组装。B想告诉A，可以的。在接口的javadoc注释里可以详细说明。不要用具体类来表明，需求要求的多了，有序你可以用具体类型告诉我，只能包含金陵十三钗你怎么告诉我呢？

后来大周末(好像是过节)的我又拉同事讨论了一下(我同事人非常好，大节假日一大早给人家发微信讨论技术问题，人家不但没打我，还耐心的跟我讨论了)，同事我说我放错重心了，主要分歧点和业务有关。和本文无关，只是澄清一下，这里就不展开了。

不要假定要证明

写了一大段例子，后来觉得不太合适又删掉了。需要举例大家直接看我之前的文章吧：《SpringBoot启动原理》、《Java异步的2种方式分析》。核心观点，在review代码的时候，代码好坏永远是第二位的，好坏之上先有对错。

断章取义

好多好多年之前，有次组内开会review code。有个很上进的同事在介绍自己的代码，我在旁边出于帮助他成长的目的，告诉他某段可以用策略模式改造下，代码结构会更简洁明了。我还补充了一下说本质上这种if else也是策略模式的一种形式，因为根据本质上是根据了不同的入参产出了不同的策略。其他人对策略模式不是很懂，所以当时大家没有深入讨论。

可能是表达不到位。回到工位后这个耿直的boy大概查了查资料，在群里说：if else不是策略模式。最尬的是年轻的leader大概也没多想，而是出于鼓励追求真理的目的还在下面点了个赞。坦白讲我当时看到有点囧，也觉得挺憋屈。我没说if else是策略模式啊。跟个小朋友在群里争论显得很没风度，不回我架构师的脸上有点挂不住。建议以后这种事情先当面和别人先私下讨论清楚，就算是别人说的不对，可以在群里转发篇文章介绍对的是啥，也别这么针对性的公开攻击式回复，真的很尬呀

总结

好坏之上先有对错

推荐阅读

工作中沟通的4点感悟

自动化回归问题的一二三(内部分享版)

Java异常处理总结

三言集锦6|不断规划与寻找自己的人生，想法把自己变重要