1 关于int.parse 的方法调用问题
我们知道int.parse用于数据类型的转换，int.parse(object obj)这个可以将填入的参数obj转换为int的数据类型。
我们在使用int.parse()时回遇到一系列问题。
例如：int.parse(null)会返回异常，另外int.Parse("4.5") 直接报错:"输入字符串的格式不正确"
int.Parse是转换String为int，得到一个object对象,你想把double转换为int,用int.Parse就不可以。
因此Int.Parse只能转换string类型的.
Parse就是把String转换成int,char,double....等,也就是*.Parse(string) 括号中的一定要是string.
综上，int.parse(s)在如下情况下回产生异常
（1）ArgumentNullException
s 为 null 引用（在 Visual Basic 中为 Nothing）。
（2）FormatException
s 的格式不正确。
（3）OverflowException
s 表示小于 MinValue 或大于 MaxValue 的数字
2同行评审
业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。
什么是技术评审？
测试和技术评审都是有效的质量控制手段，但也有明显的区别。 类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。 测试是在产品运行时进行的动态分析，测试的对象为原型、中间产品和最终产品。相对地，评审是一种静态分析，评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。
为什么要技术评审？
缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。
案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。
评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！
常见的技术评审的类型
常见的技术评审包括了走查（Walkthrough）、轮查（Pass Around）、正式的同行评审（Peer Reviews）等。
关于同行评审
在软件CMM中首次提出了同行评审（Peer Reviews）这个概念，它的目标是在产品开发过程中尽早发现缺陷，从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法（Fagan Inspection）的优点，是一种结构化的正式的评审方法。
同行评审有明确的角色定义：
协调员（Moderator）：保证评审按流程进行。
朗读者（Reader）：评审的技术领导，把焦点放在有争议的问题方面。
记录员（Recorder）：负责记录缺陷。
评审员（Reviewer）：负责发现缺陷，除了作者外，所有的其他角色都可以担任评审员。
作者（Author）：负责修正缺陷。
同行评审通常包括六个步骤：制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下：
1) 计划：选择参与者；准备检查单。
2) 准备会：分配各参与人员的角色；作者对产品作概要介绍。
3) 个人预审：评审者研究评审文档，使用检查单寻找缺陷，记录发现结果。
4) 评审会议：读者阅读评审文档，评审员发现缺陷，对有争议的问题进行讨论；作者一般保持沉默，除非读者要求对产品作解释。
5) 返工：作者修正错误。
6) 跟进：检查修正工作的进展；分析错误原因；分析评审过程，补充完善检查单。
同行评审的目的
尽可能早的发现并确定软件产品中的缺陷。
尽可能早的发现产品中应该改进和提高的部分，并及早实现。
项目成员通过同行评审，可以更好的理解软件产品，防止部分错误的发生。
