代码改变世界

怎样才能达到高效开发与彻底测试

2008-04-29 20:15  TTlive  阅读(150)  评论(0编辑  收藏  举报

来源:中国IT实验室

  “千般路”与“磨豆腐”

很久以前听一个故事:从前有个小伙子,少时有大志,长大后却无好营生,开了个豆腐作坊,每天磨豆腐累得腰酸背疼。每到夜深人静,小伙子辗转反侧,总想找条 更好的“事业之路”,可是想过千百条、尝试过几十条路,都走不通。夜不成寝,白天干活更累,小伙子不由慨叹:“晚上想过千般路,白天还得磨豆腐”。

不久以前看过一篇文章:《CMM欺骗了中国的软件业》,内容是对CMM热的反思。CMM当然不会主动欺骗人,实际上是我们的软件业自己欺骗自己。我们从来 不缺少“某某模式”,“面向某某”,“某某认证”等等听起来美妙无比的东西,问题是实际的研发过程中能做得到码?现实是残酷的,美妙的概念漫天飞舞,开发 过程仍然是作坊式的,正是:“晚上想过千般路,白天还得磨豆腐”。

中国的故事通常都有圆满的结局,现在接着说“磨豆腐”的故事。过了很长时间,小伙子终于面对现实,不再沉迷于不切实际的空想,用心磨好豆腐,闲时琢磨些个 窍门,慢慢地,他的豆腐质量越来越好,每天产量也越来越多,作坊越开越大,成了远近闻名的“豆腐老板”,后来,他做起了别的生意,发现年轻时的空想,其实 很多都是可行的,因为现在“能力”和“财力”都不同了。

再说软件开发。我们不反对任何理论、技术、方法、模式等等,但第一,您的企业或团队做得到吗?不要做“如果开发时间延长一倍,就可以做到”之类毫无意义的 假设。第二,做了真的有效益吗?效益是指扣除成本之后的收益。如果不具备这两点,那么还是不要整天想着“千般路”,首先想想如何好好的“磨豆腐”吧。

对于所有软件开发来说,代码编写都是无可逃避的“磨豆腐”。改进代码编写工作,高率效低成本地开发出高质量的代码,对于软件产品能否在激烈的竞争中胜出,对于软件企业的生存和发展,都具有重要的现实意义。

本文是Visual Unit应用的范例项目C++代码文档生成器的主题文档,叙述的正是改进代码编写工作的方法和工具,所有内容均经过实战检验,具有"可行"和"效益"两个 特征,"可行"是指较低门槛或没有门槛,凭现有条件即可实施;"效益"是指能产生立竿见影的效果。

本文所援引的范例项目,模拟最糟糕的开发团队,最混乱的开发流程:由很少写代码的测试和预研部门开发,人员不固定,时间也不固定,谁有空就写上一些;没有 设计,没有文档,基至也不在代码文件中保存编码人员的信息,成员完全依赖于阅读代码和测试用例来理解其他成员写的代码;除了简单的命名规则外,没有其他规 范,甚至连一个函数原则上不能超过50行之类的基本规范也没有(范例中有超过200行的函数CMacro::Unwind(),一万多条路径)。 任何开发团队和开发流程都会好于范例项目的开发团队和开发流程,因此,范例所展示的方法和工具,具有"广泛可行性"。

本文介绍如何进行高效编码调试和实现彻底的单元测试。编码调试是任何软件开发都无可逃避的工作,在Visual Unit的支持下编码调试,只是把本来就一定要做的工作改变一下方式,不需要多做什么,就可以大幅提高编程效率和质量;另一方面,Visual Unit彻底改变了单元测试难于实施或成本昂贵的局面,无论团队中开发与测试人员的比例是怎么样的,都可以轻松快捷地实现彻底的单元测试。

高效编码调试

任何软件开发,都离不开编码调试。对于稍为复杂一点的函数,一般来说,编写几行代码,就要执行一下,看它们是否按预想的工作,然后再继续写,写完后还要将 各种可能输入都执行一下。如何执行?一般由别的代码来调用,也就是说需要驱动,驱动通常是在开始编写函数实现代码之前建立,这样才能一边编写一边调试。驱 动大致可分为自然驱动和专门驱动。

自然驱动:利用项目中已有的代码作为驱动,通常是在被调试的函数中加断点,从界面执行一个需要调用该函数的功能,调试器中断时就可以调试了;专门驱动:为需要调试的函数编写专门的驱动代码,通过执行驱动代码来执行被调试函数。

自然驱动的主要优点是不需要其他工作就可以直接调试,甚至感觉不到需要驱动,主要缺点是输入数据通常是公共的,即很多代码都使用相同的输入源进行调试,实 际输入往往是经过其他代码处理后的中间结果,要针对各种可能输入都进行调试往往很困难,造成调试不全面,程序员的思维受到局限,难于做到全面地考虑各种可 能输入。

专门驱动的主要优点是输入数据是专门针对于被测试程序,容易做到比较全面,程序员的思维也会比较全面,对编写功能齐全的健壮的程序很有好处,要针对某种特定输入进行调试比较容易,缺点是需要花费大量的时间来编写驱动代码。

显然,自然驱动的主要问题是不全面,代码错误较多,专门驱动的主要问题是编写驱动代码很费时。有没有更好的方法,既不需要编写驱动代码,又能方便且全面地 调试?有 !这就是自动驱动,即在Visual Unit的支持下编码调试,不但无需费时间写驱动代码,更拥有多种独特的便利,可以大幅提高编码调试的质量和效率。

Visual Unit是单元测试工具,但也是高效编程调试的支持环境,在Visual Unit的支持下调试,既全面又省时:
自动生成驱动代码,但又可以方便地设定调试输入;
测试用例编辑器列出全部输入,可以很方便地检查是否全面。
除了上述优点外,在Visual Unit的支持下调试,还可以:
可视化地选择调试输入;
调试过程中还可以切换输入;
无限制的后退,重复。

上述仅是免费的个人版的功能,对于企业版用户,实际上大多数单步调试都可以省略:
自动输出参数、成员变量的输入输出值,返回值,用户也可以用简单的语法输出任何变量或表达式的值,这些数值都是上下文相关的;
显示在一个用例下,程序所执行的代码,可以很方便地查看程序是否按预想的流程执行。
程序无论多复杂,无非就是执行一些代码,读写、计算一些数据,因此,上述两方面信息已完整地描述了程序行为,一眼就能看出程序干了什么,通常可以很快判断程序是否按预想的工作并找到出错原因,比单步调试要快得多。

下面以实例来进一步分析三种调试方式的优缺点。这里所用的示例是范例项目中的CExFunction::ParseOneParameter()函数,这 是一个很普通的函数,读者也可以随便拿其他有些复杂度的代码来比较。该函数的功能是解析C++代码中的一个参数,原形如下:
PARAMETER* CExFunction::ParseOneParameter(CTokenList& iList);
PARAMETER 是保存一个参数对象的结构,定义如下:

struct PARAMETER
{
CString type; 
//参数类型
CString name; //参数名
CString defVal; //缺省值
CString array; //如果参数是数组,保存[]及[]内的文字常量
};
参数iList是一个输入参数(范例的命名规则是用i表示输入参数),传递由C++代码中的一个参数经过词法分析转换获得的记号对象序列,例如参数 int* pi,将转换为三个记号对象,分别对应于:int, *, pi。该函数将记号对象序列解析到一个PARAMETER结构的指针中,并作为返回值返回。