• 2009-08-26

    走向简单

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/45158967.html

    这是一个用C语言开发的团队,他们的程序最终会部属到一个特定的硬件平台上。

    最初的开发方式是这样的。由于系统规模很大,分了很多个模块。开发时,不同模块的人分别编写自己的代码,等到所有代码编写“完成”时,放在一起编译,生成可部属的版本。这时,要有专人搭建平台,因为开发团队的知识所限,大家通常只了解自己开发的模块,而对整个系统的配置知之甚少。当成功完成基本配置,就是把版本部属到平台上,进行测试。一旦测试出现问题,要做的就是查看代码,加打印语句,有一个专门控制台连接到这个硬件平台上,把打印语句的输出接过来进行调试。不成功的话,还要修改代码,加上更多的打印语句,重新编译版本,重新部属。我忘了说,编译版本最初要几十分钟,后来引入分布式编译,下降到几分钟的级别。

    不消说,你已经看到了上面工作方式的低效。这个团队也意识到了这个问题,如果可以把测试转到PC上来做,而不必每次都部属到硬件平台上,至少开发和调试的难度就会降低一些。于是,他们把硬件和操作系统相关的代码“隔离”开来,构建了基于PC的版本。有了PC版本,也就有了机会利用一些IDE工具,对代码设置断点。相比于原有的工作方式,新的工作方式提高了工作效率,道理上说,PC上可以验证大部分功能,不必所有的代码都拿到硬件平台去验证了。

    进一步,团队发现原有的测试都是在整个系统的层面上,所以,他们认为应该引入一些细粒度的测试。于是,他们引入了测试框架(如CppUnit),对系统内部的模块进行测试。细粒度的测试让更多的问题暴露出来,代码的内部质量得到了一定程度的提升。更重要的是,这种方式不必站在外部把整个系统驱动起来,极大程度的降低了定位问题所需的时间。

    已经进步了很多,不是吗?但这还不是终点。细粒度测试虽然不必驱动整个系统,但是为了跑这些测试,还是要运行一些初始化的工作,这些工作包括初始化内存管理、任务管理、消息队列等等。是的,目前这些测试都需要做这些工作,即便要测试的只是一个简单的“1+1”。接下来,这个团队还要继续改造之路,让简单的事可以做得简单,让测试驱动开发(TDD)成为可能,让调试不再是主要的工作方式。

    这是一条走向简单的道路,减少团队开发中消耗,把时间用在真正困难的地方。

    分享到:

    历史上的今天:

    翻译杂思 2012-08-26
    引用地址: