程序员如何有效交流？

    程序员在真正编码之前，做得最多的一件事应该就是和别人交流：和客户或者SE讨论需求，和其他模块的程序员讨论接口，等等。我们每天做的事情看似简单平常，但是我还是经常看到有人在和别人交流时，出现这样或那样的障碍，交流效率很低下，以下是我总结的几种程序员经常出现的交流障碍以及提供的建议：

    我见到过最多的一种交流障碍是：在交流的时候不注意交流的对象。例如在定位问题的时候，A模块的程序员为了证明不是自己的问题，花了十几分钟写个邮件，把模块打印出来的日志，模块内部各个组件的名字，实现机制统统贴出来，甚至还很细心的把重点用红、蓝、绿各种颜色区别开来，而收件人是什么人呢？收件人是B模块的程序员，甚至有一些根本不相干的领导。你说这些人能看懂你发的邮件的意思吗？

    其实在这种跨模块、跨领域的交流中，一定要考虑交流对象，用他们能听得懂的语言进行交流，那什么是最合适的交流语言呢？对于程序员之间来说，当然是接口。你只要把你收到的消息用他们能看得懂的形式发给他们就行了。而对于要和非程序员交流，最好还要翻译成他们能看得懂的意思，例如不要用类关系图，尽量要用用例图。

    另外一种交流障碍是：交流时，没有确定根本问题。经常出现的是：XY问题。例如，我本来要解决的是X问题，我想到了某种方法，但是这个方法中有个搞不定的地方，我们叫做问题Y，我拿着问题Y去向别人找答案。这种方式在某种程度上能尽快的找到解决方案，因为一般来说X问题比较复杂，而Y问题已经相对来说很简单了，很容易在别人那里得到答案。但是我们说是在某种程度上，也就是说是有前提条件的：你对于问题X的解决方案是合理的，那么得到的Y问题的答案才对最终你想解决的问题X是有用的。相反，如果你对于问题X的解决方案不是合理的，即使得到Y问题的答案也于事无补，更有甚者，Y问题有可能根本就是一个很难解决的问题，导致你根本找不到答案。

    例如，我前几天就遇到过一个真实的案例，SE根据用户要求，需要从User Agent信息中提取手机终端的型号信息，由于UA信息是对于每个手机厂家都不一样，所以想要找出一个对于所有UA信息都有效的提取手机型号算法是很难的。我就问SE，用户为什么需要手机类型的信息呢？SE说为了区分高端用户和低端用户，对于不同用户采取不同的营销手段。我就反问SE，那是否可以通过用户的日消费金额，月消费金额来区分呢？

    其实这里讲的是关于需求分析的案例，同时也导出了对于XY问题的一个解决办法：弄清楚X问题是什么？在不确定X问题的方案是否为最佳方案时，不要直接拿方案来讨论，而是拿原始X问题来讨论。

    这里有篇X-Y Problem专门说XY问题。

    还有：别着急提方案，先想好问题在哪