DotNet程序之找BUG心得

这篇文章仅仅是写如何找BUG，只是列出本人这些年来用.net编写程序过程中寻找BUG的一些方式方法，欢迎大伙踊跃跟帖，你的轻描淡写，或许能解除某些人心中由来已久的迷团。

写程序有了BUG是经常的事情，只是它们形式多样，有的直接能看到，有的隐藏比较深，从表象看几乎不能看出来，只有特定的场合能诱发、激活这种BUG，
我们以前经常听到别人讲要如何规范化写代码，注意层次，藕合度，函数的行数等等，这些良言佳句的确能减少我们出错的几率和排错的时间，但人不是机器，出错总是会有的，出了错，如何及时有效地把它揪出来予以更正是最最重要的。

下面我以经常遇到的BUG，结合我的经验谈谈BUG解除之道。
1、显而易见的BUG。在运行web页面或winForm程序时，在页面上、程序界面爆出来的出错提示，某文件或某行出错。这种BUG是比较容易找到，并且可以较为轻易清除的，我们只要按照出错提示找到相应的行，再找出问题所在即可。
2、隐藏的BUG。在常规方式，或者说理想状态下运行时，程序表面一点问题也没有，但是因为客户端环境变化，或者客户提交的参数比较特殊，因为你的一时粗心大意没考虑到这种情况，就诱发了这种BUG的产生。其实只要找到当事人要清除这类型的BUG也不难，但几乎不可能找到诱发此BUG的当事人了。那你就要重新考虑所有的极端情况了，编程不能永远以理想状态去考虑。事实证明，在考虑参数的时候一定要把所有极端情况都考虑进去，例如你希望得到一个int?的参数，就必须同时考虑负数，0，NULL值，MaxValue,MinValue等，缺一不可。因为你永远不能指望客户端按你的理想状态来交互。

解决之道：

1、断点法：
　　

　　不论是显而易见，或是藏头露尾的BUG，我们在不能确定具体出错位置的时候，都可以用这种方法.

操作方式是在VS的操作界面上在某一行点右键，弹出菜单中选择“BreakPoint”=》Insert BreakPoint

或直接在左侧灰色框上点鼠标左键。出现一个红色实心小圈，说明你成功在此下了断点。

如果是WEB应用程序，我们可以在右侧解决方案窗口右击某文件，选择“Set as start page”。

最后按F5或从Debug菜单中选择“start debug”或直接在界面中点击绿色的“播放”键。

当程序运行到你指定的断点时，会停下，然后你可以比对上下文，查看各种数据、参数是否符合你的预期。如果有误差，说明在此断点之前BUG就已经产生，在此之前继续下断点，并重复此DEBUG过程；如果在断点这里，所有数据及参数都符合你的预期，那么你可以继续以其后下断点，直到找出错的行。
2、最小系统法：
　　

　　有时候，面对一个庞大而又有BUG的逻辑，我们会手足无措，不知道该从何下手，光用断点去调试有点费时间，这个时候，应该辅以最小系统法，把心里认为最有可能出错的代码行注释掉，再行编译调试，这样能迅速缩小搜寻范围。毕竟最后问题会指向某个方法中，而这个方法如果按规范来，不会超过13行代码。当然你会说如果我所有的方法都超过130行怎么办？那我建议你先把方法优化一下，把大块头的方法分装成小块头再进行调试。这个建议其实不仅仅对于调试，而且对于以后的代码维护甚至系统升级、代码复用、代码移植都有非常大的好处。
3、直接给值法：
　　

　　有时候某个方法莫名其妙报错了，也许你有LOG，记录下了出错的地方，但你其实通过LOG只找到了“未将对