昨天跟同事Q一起看他接手的D模块的代码，这块代码是由同事Y编写的，因为Y离职，由Q来接手负责该模块的维护及开发。在工作交接时，Y已经把代码的逻辑完全跟Q讲解过，只是在我检查Q交接工作时，发现Q并没有理解Y的代码逻辑，让Q重新找Y交接工作。本来我觉得经历上次的批评，Q对该模块的掌握应该是很清楚了。但是昨天找他问了三个问题:
1、为什么模块中要区分2016-12-07两种处理方式，而且代码逻辑一样？
2、这个模块整个代码的作用是什么呢？
3、模块中某行关键代码是什么意思呢？
针对三个问题，他给出的答案是:不清楚，需要了解一下。我无奈的答应三个小时之后再问他。
经过跟同事Y和自己仔细理解程序逻辑之后，他回答了我上述问题的逻辑。这个时候我又有新的问题出现了。
我:这个程序逻辑应该可以优化一下吧？因为这样的处理逻辑非常绕哈。
Q:这个程序处理逻辑只能这样处理，我觉得可以理解哈。
我:你看整个代码的目的是为了统计全年的交易笔数，可以用全关联的方式实现累加的。
Q:我问过Y了，可能存在性能问题。
我:你有试过吗？
Q:没有，我觉得拆开肯定比一起执行效率高哈。
说到这里我无语了，觉得没有必要沟通下去了。因为他的认知已经无法支撑接下去的讨论了。
他的认知有以下几个问题:
1、态度问题。工作交接没有认真对待，无法做到一次交接，需要反复交接。
2、不转化。因为每个人的思维方式不一样，导致代码的思路也不一样并且Y编写的代码确实比较差，他并没有将同事Y的思路转为自己可以理解的思路，并针对此提出优化问题，导致每次都需要理解同事Y的思路。
3、以偏概全。针对任何的解决方案都有其假设前提，他只接受了结论，并没有考虑该结论的前提是什么，是否符合了这个前提。
4、模糊答案。针对问题的答案有太多的可能，估计，或许，并没有给出肯定的答案，让人心里没有底。
