当需要时，适合设计或者编码上下文的模式、惯例、编程规范，将“自然地”从自己的潜意识中冒出来，这说明正确使用了模式、惯例、编程规范的一种迹象；

　　识别陷阱与对条件的反射类似，一朝被蛇咬，十年怕井绳。然而与比赛和打仗一样，为了学习如何识别和避免危险情况，并不需要一定被烧伤或者被枪伤。一般情况下，必要条件是提前警觉；

　　（4）设计模式和重构是什么关系？

　　设计模式给我们的，不仅仅是一些问题的解决方案，更有追求完美“模型”的渴望，但是，Joshua Kerievsky在那篇的《模式与XP》中明白地指出：在设计前期使用模式常常导致过度过程。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，“实用”是软件压倒一切的要素。

　　（5）快速理解源代码和重构是什么关系？

　　进行重构时，您从一个能够正常工作的系统开始做起，希望确保结束时系统能够正常工作。一套恰当的测试用来可以帮助您满足此项约束，所以重构应该从编写测试用例入手。一种类型的重构专注于修复一种已知的问题点。在此，您必须理解老的代码、设计新的实现、研究新的实现对相关其它代码造成的影响（多数情况下，新代码能够“无声无息”地完成替换）并实现更改，所以重构需要先快速理解老的代码。

　　（6）快速理解源代码查找缺陷和寻找设计陷阱查找缺陷有什么不同？

　　快速理解源代码找出的代码中的问题一般是流程设计上和软件需求满足上的特定的问题，需要读者翻很多页（发现前后的关联），而寻找设计陷阱找出的代码中的问题一般是普遍性的问题，一般不需要读者翻页，在这一行的上下文中可以找到。

　　（7）这几个层次的代码走读和单元测试是什么关系？

　　只有快速理解了源代码才可以完成单元测试，或者说快速理解源代码是完成单元测试的前提；

　　利用单元测试可以帮助更好地重构；

　　代码走读发现的问题比单元测试发现的更多、更快和更早；

　　单元测试发现不了不满足编程规范的问题

　　（8）代码走读都有哪些方法？

　　形式上可以遵从同行评审的结构化的正规检视、走查、单人复审等；

　　人工走读时，检查单可以按照头脑风暴、亲和图、鱼骨图方法形成系统化的检查树和处理机制；

　　工具走读可以借助一些商用的测试工具和自己开发的辅助工具进行走读。

　　（9）代码走读听起来是不错，如何才能达到效果吗？

　　代码走读中使用的检查单（或检查树）是很多人提炼和总结出来的结晶，市场和业界这方面的资料比较缺乏，因为多是个别大公司或个人的心血，所以很少在外面流传，自己研究和总结有点得不偿失，不如参考行业的实践，所以好接受有经验的专家的培训或向有经验的同行请教，在指导下开展推行，避免浪费自己的宝贵时间。

　　（10）代码走读和同行评审是什么关系？

　　同行评审是一种比较偏管理的方法，评审的材料可以包括文档和代码，对于代码的同行评审是代码走读，本文讲的代码走读偏重于技术层面的方法，两者只有有效地结合才能更大地发挥它们的威力！