建议回答时，采取避重就轻的策略，说一个同行评价自己的无关紧要的小毛病，然后重点说说同行对你的一些比较中肯的好的评价。

"评审软件产品有很多种方法。其中主要的有审查、预排和个人评审。。。" - Watts S. Humphrey----《A Discipline for Software Engineering》 同行评审的目的是及早地有效地从软件工作产品中消除缺陷，由此产生的一个重要效果是建立对于软件工作产品及其可以被预防的缺陷的更好的理解。同行评审包括软件产品制作者的同行对该软件产品进行系统检查以识别出缺陷和需要更改的地方。项目已定义的软件过程中确定了将被进行同行评审的具体产品，项目策划中纳入了进行这些同行评审的具体计划。同行评审着重介绍如何进行同行评审。其它有关开发/维护软件产品的关键过程领域描述了如何识别将被进行同行评审的具体软件产品。附图对过程说明一下：

评审尤其是同行评审，是提前发现缺陷，降低开发成本的有效方法；
但是很多企业并不重视，或者效果不佳。
原因有很多：没有获得合适的专家、组织不合理、方法不当等。
针对代码评审，想简单地谈几点（其实其它工程文档的评审存在同样问题）：
1、评审要计划。
因为大家都很忙，各领域的专家也都有各自的工作，评审结果的好坏对工作绩效没有影响，所以专家投入多少精力来用于评审不受控，完全靠自己的职业精神。
所以，这就要求项目经理比较有影响力，能够争取到足够的、合适的专家来参与评审。
专家最好要提前协调，当然项目经理首先要知道要请哪些专家（如系统专家、领域专家、测试人员、QA等），这些专家在哪里。能否获得专家资源的支持，是项目经理的项目管理能力一个重要体现。
评审时间的投入比例，一般是第一次版本准备时间的3/5以上。
2、评审要分层次和重点。
作为项目成员，在代码编写完成后，首先是自检，这时发现的缺陷不计算；
然后是项目组内的评审，这时发现的缺陷应计算；
最后才是外部评审。
应提前把相关文档和代码交给评审专家，让各自评审；
根据项目和评审结果的情况，决定是否召开评审会议，评审会议以确认问题为主，而不是讨论解决方案。
对于重要的核心的代码，要投入重点评审力量；
另外，对于能力不足的成员所完成的代码，也要重点评审。
每个角色也应明白各自评审重点，如QA重点放在编程规范、测试人员侧重在可测性、系统专家侧重在从整体来考虑（如对其它功能的影响、性能等）。
3、问题的确认与跟踪。
评审专家发现问题后，首先与该代码的完成人进行确认，如果大家达成一致认可这个问题，然后由代码完成人提出解决方案，这个解决方案要得到问题发现者的同意，然后编程人员编码实现该方案，并进行测试和验证，并将验证结果提交问题发现人，问题发现人确认无误后，该问题就可关闭。
所以，评审专家发现问题后并没有结束，而是要负责跟踪该问题。
总之，评审活动的组织其实比较复杂，也是项目经理项目管理能力的一个重要体现，项目经理对评审活动负有重要责任。