每个人对自己出产的交付件（文档、代码、测试用例等等）多少有些护犊之情，一方面不愿意挑刺，另一方面存在盲区。由于个人的思维定式，信息不足/缺失，导致交付件中的瑕疵、隐患不太容易被发现。问题一旦遗留到后期，维护、修改成本将大幅放大，推高了业务、产品的整体交付成本。
通过三个交叉：交叉review、交叉串讲、交叉验证，经由同行的审视(Peer Review)，可以从不同的角度，发现隐藏的瑕疵、隐患。
· 同行更愿意用挑剔的眼光审视。
· 由于同行也在同一领域耕耘，已经积累了自己的经验，对被审视的交付件有自己的想法，更容易发现分歧点，发现不妥的地方。
· 每个人的经历一样，对同一个问题的看法角度、深度也不同。通过同行审视，可以从多个维度、不同层面看待问题。
· 相互学习提升。对于不了解的同行，可以通过三个交叉迅速学习，并应用于实际工作中。通过老带新，快速上手新的业务。
· 参与的同行必须保持好学心态，不能固守自己的一亩三分地。一方面保持空杯心态，对新业务愿意学习；另一方面保持批判心态，利用已有经验、知识，用批判的眼光审视业务。
· 参与的同行最好有一部分具有丰富的经验，可以帮忙发现问题。
交叉reviewreview对象：方案、预分析文档、代码、测试用例等开发过程中产生的交付件。
review频率：大的交付件可以在开发过程中即review，及早review，将问题消除在萌芽阶段，可以大幅降低后期的解决成本。
review的过程中，可以思想碰撞，相互交流。
正式的review，一般要求作者讲解自己的交付件。通过讲解，一方面加深作者自己的理解，另一方面打开同行的思路。往往作者在讲解的过程中，自己就可以发现一些问题。
交叉验证交叉验证：A开发的特性（特性即可以是一段软件代码，也可以是一个硬件模块），交由B进行验证。其中的验证，就是模拟实际应用场景，验证交付特性的可用性、稳定性等等。
A验证自己开发的特性，容易陷于思维惯性，导致验证不充分。另外，开发人员多少对自己的特性有护犊之情，不愿意揪出其中的Bug，导致问题遗留到下一阶段。
通过交叉验证，B可以快速了解新的业务、特性，同时可以发现其中的瑕疵。由于B没有思维惯性，可以从不同的角度、不同的深度对业务深度测试。
交叉串讲交叉串讲：A编写的代码、文档，交由B来讲解。要做好讲解，对B的要求很高，所以对B的压力也很大。因为代码、文档不是自己写的，很多细节需要B深度了解。在讲解之前，需要做很多功课，熟悉对应的方案设计、预分析文档，熟悉相关的业务，不了解的地方，及时咨询模块开发人员。
在整个A、B互动的过程，A同时也完成了一次业务的审视，在交流过程发现的问题，可以及时记录并解决。通过交叉串讲，锻炼了B，完成人员备份、人员培养。后续A有工作调准，B可以顺利接手被串讲的模块。
通过交叉串讲，开发工程师可以跨出自己的一亩三分地，从熟悉单模块走向熟悉多模块，最终做到全局业务的了解。
