重构-断言
现象：某一段代码需要对程序状态做出某种假设
做法：以断言明确表现这种假设
动机：
常常有这种一段代码：只有某个条件为真是，该改名才能正常运行。
通常假设这样的假设并没有代码中明确表现出来，必须阅读整个算法才能看出。
有时程序员会注释这样的代码。
而现在这种重构介绍一种更好的技术：使用断言明确标明这些假设。
断言是一个条件表达式，应该总是为真。如果他失败，就是bug。
因此断言的失败应该是一个非受控异常，断言绝对不能被系统其它部分使用。实际上，程序最后的成品往往将断言系统统统删除，因此，标记某些东西是个断言是很重要。
断言作为调试和交流的辅助，在交流角度，断言可以帮助程序阅读者理解代码所做的假设；在调试的角度，断言可以在距离bug最近的地方抓住它们。
做法：
如果程序员不犯错，断言就不会对系统造成任何影响，所以加入断言永远不影响程序的行为。
如果发现某个条件始终为真，就加入一个断言说明这种情况。
可以引入一个assert类，用于处理各种情况下的断言。
不要滥用断言，请不要用来检查你认为应该为真的条件，请只用来检查一定为真的条件。滥用断言可能会造成难以维护的重复逻辑。
在一段代码中引用断言是有好处的，他迫使你重新考虑这段代码的约束条件。
如果不满足这些约束条件，程序也可以正常运行，断言就不能带来任何帮助，只会把代码变得混乱，并且可能妨碍以后的修改。
如果断言的所指示的约束条件不能满足，代码是否正常运行？如果可以就把断言拿掉。
还需要注意断言中重复的代码。
C# 断言代码
- System.Diagnostics.Debug.Assert(b1);
断言(Assert)与异常(Exception)
断言是被用来检查非法情况而不是错误情况，即在该程序正常工作时绝不应该发生的非法情况，用来帮助开发人员对问题的快速定位。异常处理用于对程序发生异常情况的处理，增强程序的健壮性、容错性，减少程序使用中对用户不有好的行为，不让(通常也不必)用户知道发生了什么错误。
实际开发中，我们通常将Assert与异常混淆， 不知道什么时候使用Assert，什么时候使用异常处理。或者不用Assert，将一切情况都归为异常。这样一来，就掩盖了问题，当问题发生的时候，很难进行定位，而这些问题本该是在开发的时候就解决掉的。同时，也增加了开销(在c#中，debug.Assert()编译成release版本时，不会产生任何代码，而try/catch在debug/release版本中都是有代码产生，运行时需要开销)。