一、“千般路”与“磨豆腐”
很久以前听一个故事:从前有个小伙子,少时有大志,长大后却无好营生,开了个豆腐作坊,每天磨豆腐累得腰酸背疼。每到夜深人静,小伙子辗转反侧,总想找条更好的“事业之路”,可是想过千百条、尝试过几十条路,都走不通。夜不成寝,白天干活更累,小伙子不由慨叹:“晚上想过千般路,白天还得磨豆腐”。
不久以前看过一篇文章:《CMM欺骗了中国的软件业》,内容是对CMM热的反思。CMM当然不会主动欺骗人,实际上是我们的软件业自己欺骗自己。我们从来不缺少“某某模式”,“面向某某”,“某某认证”等等听起来美妙无比的东西,问题是实际的研发过程中能做得到码?现实是残酷的,美妙的概念漫天飞舞,开发过程仍然是作坊式的,正是:“晚上想过千般路,白天还得磨豆腐”。
中国的故事通常都有圆满的结局,现在接着说“磨豆腐”的故事。过了很长时间,小伙子终于面对现实,不再沉迷于不切实际的空想,用心磨好豆腐,闲时琢磨些个窍门,慢慢地,他的豆腐质量越来越好,每天产量也越来越多,作坊越开越大,成了远近闻名的“豆腐老板”,后来,他做起了别的生意,发现年轻时的空想,其实很多都是可行的,因为现在“能力”和“财力”都不同了。
再说软件开发。我们不反对任何理论、技术、方法、模式等等,但第一,您的企业或团队做得到吗?不要做“如果开发时间延长一倍,就可以做到”之类毫无意义的假设。第二,做了真的有效益吗?效益是指扣除成本之后的收益。如果不具备这两点,那么还是不要整天想着“千般路”,首先想想如何好好的“磨豆腐”吧。
对于所有软件开发来说,代码编写都是无可逃避的“磨豆腐”。改进代码编写工作,高率效低成本地开发出高质量的代码,对于软件产品能否在激烈的竞争中胜出,对于软件企业的生存和发展,都具有重要的现实意义。
本文是Visual Unit应用的范例项目C++代码文档生成器的主题文档,叙述的正是改进代码编写工作的方法和工具,所有内容均经过实战检验,具有"可行"和"效益"两个特征,"可行"是指较低门槛或没有门槛,凭现有条件即可实施;"效益"是指能产生立竿见影的效果。
本文所援引的范例项目,模拟最糟糕的开发团队,最混乱的开发流程:由很少写代码的测试和预研部门开发,人员不固定,时间也不固定,谁有空就写上一些;没有设计,没有文档,基至也不在代码文件中保存编码人员的信息,成员完全依赖于阅读代码和测试用例来理解其他成员写的代码;除了简单的命名规则外,没有其他规范,甚至连一个函数原则上不能超过50行之类的基本规范也没有(范例中有超过200行的函数CMacro::Unwind(),一万多条路径)。任何开发团队和开发流程都会好于范例项目的开发团队和开发流程,因此,范例所展示的方法和工具,具有"广泛可行性"。
本文介绍如何进行高效编码调试和实现彻底的单元测试。编码调试是任何软件开发都无可逃避的工作,在Visual Unit的支持下编码调试,只是把本来就一定要做的工作改变一下方式,不需要多做什么,就可以大幅提高编程效率和质量;另一方面,Visual Unit彻底改变了单元测试难于实施或成本昂贵的局面,无论团队中开发与测试人员的比例是怎么样的,都可以轻松快捷地实现彻底的单元测试。
二、高效编码调试
任何软件开发,都离不开编码调试。对于稍为复杂一点的函数,一般来说,编写几行代码,就要执行一下,看它们是否按预想的工作,然后再继续写,写完后还要将各种可能输入都执行一下。如何执行?一般由别的代码来调用,也就是说需要驱动,驱动通常是在开始编写函数实现代码之前建立,这样才能一边编写一边调试。驱动大致可分为自然驱动和专门驱动。
自然驱动:利用项目中已有的代码作为驱动,通常是在被调试的函数中加断点,从界面执行一个需要调用该函数的功能,调试器中断时就可以调试了;专门驱动:为需要调试的函数编写专门的驱动代码,通过执行驱动代码来执行被调试函数。