代码健壮性--理论篇

   在这次ITOO技术小组里，我选择了“代码规范”这个方向进行研究，在对代码注释、命名、SVN规范等了解了之后，最让我感到兴奋的一点就是：代码的健壮性。

   期初浅显理解：

   健壮性是指软件对于规范要求以外的输入情况的处理能力。所谓健壮的系统是指对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。

   也就是说，最初的理解类似在机房收费系统中，输入的文本框是否是规范的值，比如卡号输入一些乱码等，这样的理解仅仅停留在了表象上。

 

   后期深层次理解：

   健壮性是指程序可以适应正常和非正常的运行环境，都可以正确地运行；随着业务量的增加，不会出现阻塞和不可用的情况（官方概念）。

   举一个简单的例子：如果一个人很健壮，那么他在遇到一些小毛病的时候，比如感冒，能够很快恢复，而不至于遇到感冒就倒掉了

对比过来，就是如果一个程序很健壮，那么他在遇到感冒的时候（比如，想要打开的文件不存在），也能够很快恢复（处理异常情况，输出错误信息等），然后继续运行下去，而不至于一遇到感冒就die了。

   简单的说，健壮性的代码就是遇到问题不容易崩溃的代码。

   健壮性的思想：

    (1)正常运行的代码.首要追求高效性

   这个"高效性"如果从逻辑的角度来解释,那么一方面是"高效"地对正确的数据执行正确的算法(方法/策略),另一方面是"高效"地找出异常,然后丢给异常处理代码去处理.

    (2)处理异常的代码.首要追求健壮性. 

   就是程序必须能从异常中自我恢复.由于代码多数时间跑的是"正常"逻辑,少数情况下才不得不处理"异常",所以"异常"处理的代码中,首要任务是健壮,跑不死,而高效性则是次要的.

    这里谈一下我的认识：

   “正常运行的代码”和“异常处理的代码”类似于：

//或者使用try catch 方式if (判断传入参数的类型是否匹配)  {      //"正常运行代码"     //匹配，走正常处理流程, 直接把返回值传给上层逻辑处理  }   else  {      //"异常处理代码"       //不匹配，走异常处理流程，重新扫描传入的数据，或者给出提示8. }  

   两种不同类型的代码，所追求的方向不同，前者，保证了正确的前提下，要去追求代码的效率；后者，已经知道了这是问题，就要把问题可能出现的原因考虑清楚，然后去排查错误，保证代码的正确运行。而不是在不会出问题的代码段花更大的力气去确保其健壮性，做到各司其职。

   健壮性运用的思考：

   1、在做前台页面过程中，对于ASP.NET验证控件的使用、正则表达式的使用，要融入到我们的日常编程习惯当中。传到后台的错误（类似于到B层逻辑判断进行不下去）才发现的错误，在前台一定要保证根本不让这些参数传入到后台，扼杀在摇篮中。

   2、合理布局函数返回值，保证函数返回值一致

   之前很多时候写函数往往很随性，返回值类型可以能代表函数执行成功或者失败的Bool型，也会有代表实际结果的Str或者Int等类型。这样的函数在外部调用时痛苦非常，因为在函数调用后处理时，处理不当就会出现typeError，所以在函数编写前，要思考后本函数的作用，同时确定返回值类型，在函数的所有涉及到返回结果时，给予一致类型的返回值，方便外部调用。

   3、必要情况下的Try…Catch…处理

   Try…Catch…出来处理异常是各种语言都有的模式。但到底在何处使用却有讲究。在没有抛异常的语句使用try语句，会降低性能，带来代码冗余，而在需要处理的语句未加异常处理，则会带来运行崩溃的可能。所以，要深刻的了解代码的语句，是否存在抛异常的可能，对可能抛异常的语言要加以处理。（这方面的介绍在下一篇实战博客中会进行讲解）

   4、清理代码，去掉冗余代码

    很多时候，我们的代码都是迭代开发的。往往会罗列一些无用的函数，引入一些无用的类库。这些内容貌似无意义，但却是代码中的隐患。可能在后续的类库更新或者函数变更中爆炸。所以，代码要保持清理，对于无用的引用和定义，要加以清除。

   其实对于健壮性的思考，咱们在做系统开发的时候，现阶段考虑的比较少，主要是对于实现功能的追求，在做过几个项目之后，这方面的涉猎应该开始了，保证自己功能实现的情况下， 让自己的系统“不容易那么崩溃”，才是我们所追求的。

    另外，解铃还须系铃人，在进行代码健壮性思考的时候，一定要去查看常见的代码错误的几种类型（是逻辑错误还是编译有问题？等），从问题出发，就能更好的进行健壮性处理。

   下一篇博客将从“异常处理”的角度对代码规范进行实战总结。