题图：by Rene Magritte
王小波式的诙谐，往往是非理工科的人难以欣赏的幽默。所以可能这就是为什么在当今这个理工男（女）泛滥的年代，更多的人喜欢他。
比如说，他明明知道数学证明里一个严谨的逻辑证明是什么样的，却还是故意用似是而非的逻辑去把一件似乎无赖的事说的合理无比。
举个例子。
他被队长冤枉说他打瞎了队长家母狗的左眼，于是说：我想证明我自己的清白无辜，只有以下三个途径：
队长家不存在一只母狗；
该母狗天生没有左眼；
王二是无手之人，不能持枪射击。
然后他说因为三条一条也不成立，队长家有一条狗，狗天生有左眼，王二有手，所以他就没法证明他是无辜的了。
再举个例子。
后来陈清扬被造谣说和王二搞破鞋。陈让他证明他们无辜。结果他又说：我要证明我们无辜，只有证明以下两点
陈清扬是处女；
王二是天阉之人，没有性交能力。
然后他认为这两点都难以证明，所以他们不能证明自己无辜。
一条条写的比考试答案还有条理。其实这不过是简单的 A => B 并不等价于 非A => 非B。但若不想通这一点，这样的歪理往往让人一时难以反驳。
当然，因为这个逻辑太离谱，所以才是一种幽默。因为就算你推不倒他的证明，也知道这是错的。
分割线。
工作中有时候我们会遇到这样的情况：自己和别人关于一件事的做法有不同意见。而且开始的时候似乎很难说服彼此。虽然自己觉得自己是对的，但是别人说出一些话来却又似乎无法反驳。这个时候要怎么办呢？
如果是无关紧要的，其实不用事事争长短，说出自己的意见就行了。但如果是对后期的工作量、工作方向、甚至是项目的架构有紧要的关系，又该如何呢？其实，我自己有时候也会面临类似的情况，不过遇的多了，每次大概会从这样几个方面考虑或尝试。
一，两个方案的比较是不是 “Apple to Apple” 在比较。你拿一个苹果和一个橘子比，就很难有结果。一个现有的已经实现的系统，和一个系统的方案，比较起来，一定是更容易看到已知系统的问题，和设计蓝图的完美。
二，很多时候，纯从理论出发，最后各自都执着于自己的理论，就很难站到一起。拿几个实际系统中的场景作为例子，细致地比较两个方案落实到这些场景和例子的优势和劣势。罗列出来，就更能预见到方案采用后的优劣。而且要注意，很多时候，一定是一个方案在一些场景中更好，另一个在另一些场景中更好。这种时候，也要考虑哪些是主要场景，并尽力能的优化更常见的情况的处理。但是对特殊情况，也要有一个限制。这倒很像我们常说的平均复杂度和最坏复杂度。
三，每个公司，都会有一些技术上的要旨或指导准则，也就是所有设计需要尽可能遵循的规则。如果能从中找到适用于你的争论上的条例，应该尽可能考虑或作为争论的依据。比如一些常见的技术设计的指导准则：
尽可能使用标准的库和函数。
保证系统的可扩展性。
一定程度上保留设计灵活度，但不要过分优化设计。
保证每个服务尽可能独立通用，不要过度耦合。
等等等等。
四，可以去请教一些双方都信服的老人，甚至是对产品或系统某一方面特别熟悉和了解的不那么老的人。也许争论双方对某一点的看法，在引入一些新鲜的见解的时候，更容易看得明朗。但也要注意不要搅入太多不太了解情况的人，除非你已经准备好花很多时间跟他们从头解释清楚，或是觉得这样的精力值得。否则，对争论有个结果帮助不大。
五，有的时候，虽然看起来好像两方的意见和方案完全相反，但是如果把双方的侧重点或者问题本身拆分，也许你会惊喜地发现，双方当仁不让的点，其实并不那么冲突，有可能把两个方案拆分成两 “套” 包括多个小方案的方案。而决定可能是这两套方案的组合。虽说这个做法有一定的灵活性，但实际中一定要把组合后的方案从头到尾想清楚。否则可能出现拿着 A 方案的假设，去评估了 B 方案的某一部分可行性的情况。
其实，技术人之间的争论，只要双方都通情达理，一定能找到一个双方都满意的结果。因为其实很多决定，都还是有逻辑和道理可循的，而技术人如果不通逻辑，那问题就不仅仅在这场争论了。另外，如果争论的双方在某一些方面难分伯仲，还是应该尽可能尊重执行者的意见，毕竟，系统的实现和维护是他们做。
分割线。
回到开始举的那两个例子。再教你一招。你要证明我的方案一定是错的，只有证明以下两点：
有人用和我一摸一样的方案，建了一个系统，但是完全行不通；
我从来就没有对过。
因为你没法证明这两点，所以我的方案一定是对的。你说是吧？
