谈应用程序内在质量的改善

　　谈应用程序内在质量的改善  软件测试

　　1.可维护性

　　代码的可维护性和可扩展性的第一责任在架构,因为架构要做相关的分析模型,划分相关的单元模块和接口,考虑组件和复用等各方面的问题. 架构设计是高层次的往往只抽象出相关的类和包,对于每一个类中应该设计哪些方法和函数,并如何组织这些方法和子函数的调用关系,还必须进行详细设计,这是编码的可维护性和可扩展性的两个最基础的内容.

　　能够准确表达代码实现意图的言简意骇的注释是源代码可读性的一个重要内容.好的源代码应该是可以自解释的,因此注释不应该太多也不应该全是些照字面翻译语句的垃圾注释.注释的量一般占代码总量的10-20%就可以了(如果注释量超过30%说明垃圾注释太多,代码的自解释性不好很多应该拆分为子函数的没有拆分等原因).源代码文件的文件头要有注释说明整个类的实现功能和流程,调用多个子函数的主方法方法头要有明确的实现意图和调用步骤的注释(很重要),以方便维护人员和自己阅读代码.

　　方法和变量命名等要严格遵守相关的编码规范进行命名.名称不要怕长,名称要能够完全的体现出方法所实现的功能.如根据某一客户编号查询其的所有定单,则GetInfo,GetOrderInfo等不是最好的方法名.而应该采用GetOrderInfoByCustomerNo,通过这种方法名称即使不加任何注释其它人员也可以很好的阅读你写的代码.

　　一个类文件建立代码行不易超过2000行,超过2000行都应该拆分相关的扩展类或Helper类.在一个类文件中一个方法或函数不易超过50行,超过50行的可以考虑拆分相关的子函数.但这个规则也需要灵活考虑,比如对于一些数据有效性或完整性判断的函数,超过50行一般不会存在任何问题.

　　每个软件开发项目开发前都应该定义相关的编码约定或规范,该文件包含了命名,缩进,注释,布局等各方面的内容,在此就不再做过多的叙述.

　　2.可扩展性

　　编码可扩展性的源头是需求的可扩展性,首先需求人员要在需求分析过程中分析出哪些需求是易变化或会扩展的需求.只有需求考虑到了可扩展性,架构在设计过程中才能够有针对性的进行设计,否则只能够后期对代码进行重构来实现源代码的可扩展性.

　　可扩展性基于原有的经验积累和他人的最佳实践.充分理解面向对象分析和设计的思想和重要的设计模式.设计模式的精髓就是面向接口设计,而这个也是保持代码的可扩展性的一个重要思路.另外在面向结构方法中我们对数据表的字段或方法参数预留一些扩展字段也是常用的支持系统扩展的方法.好的扩展性的判断准则有

　　a.设计到需求变更或新需求时候或是新增类文件或是新增方法,而不是对已经有的多个源代码文件造成影响

　　b.设计一些简单的扩展时候,可以灵活的通过配置文件来实现而基本不用修改源代码

　　我们对需求的理解也是逐渐细化的过程,因此一开始就得到完全健壮的代码是很难的,通过需求的不断细化和需求的变更来Review我们的代码实现,适时而不断的对代码进行重构才可能得到健壮和可扩展的代码.

　　3.安全性

　　安全性仍然属于代码内在质量的一个内容.但平时在开发过程中往往并不会特别注意代码的安全性.对于软件系统的安全性基本可以专门开专题来讨论,在这里仅仅简要说明一下.

　　首先是源代码应该防止被反编译,相关的重要数据和数据库连接串等信息都应该加密进行存放.其实是在分布式应用中要注意数据传输的安全性,防止数据被非法获取.对于暴露的远程服务要注意身份认证和识别,防止他人伪造客户端进行调用.其次整个系统应该有完善的权限模型,除了最简单的业务功能权限外,还应该根据需要对系统中相关的业务对象有完善的静态权限和动态权限的控制机制.

　　4.系统的健壮性

　　系统的健壮性比较重要的一点就是系统对异常的捕获和处理能力.因此对于一个软件系统应该有完善和独立的异常处理和日志记录机制.当出现不可预见的错误时候不会导致整个软件系统或操作系统的崩溃.同时系统还需要记录足够的异常和日志信息,以方便后续维护人员对问题进行跟踪和分析.

原文转自：http://www.ltesting.net