必须上来写点,否则对不起订阅BLOG的读者了。
这周我们封闭开发,重构pFind引擎内核引入Trace机制。我预研了Log4cpp和ACE_TRACE的源码,还是决定自己动手实现底层机制,更贴近pFind系统的实际要求。
像pFind这样的复杂系统,不免有大量输出信息,有些是给用户看的,有些是程序员调试时用来追踪进度和现场情况的。传统做法,调试信息会被用宏开关控制,产品发布时被关掉,以免输出过于庞杂导致用户体验变差,但这又会增大事故现场诊断Bug的困难。要调和这对矛盾,就需要灵活的Trace机制,通过设 置参数实时控制输出,例如范围(指定的算法模块、线程或集群节点)、级别(过滤或保留debug信息)和目标(命令行输出或写入日志文件)。
这种基础设施涉及到整个系统,大部分模块都需要重构,工作量不小。在Win32下开发调试比较顺利,移植到曙光大机的64位Suse Linux时,出现了一些动态链接问题,调整了模块划分。(为了解决这个问题,去查阅俞甲子、石凡和潘爱民的《程序员的自我修养——链接、装载与库》,的确是好书。)
遇到了Gcc 3.4.5的这个Bug,编译STL总会出现大量Warning。从GNU Bugzilla上的讨论来看,Gcc 3.*系列的维护已经停止了,推荐升级到4.*系列。一直想升级pFind的默认编译器,但之前尝试时,ACE在Gcc 4.4(MinGW)下无法正常编译(刚刚搜索,貌似今年1月份刚刚有人把这个Bug解决掉了)。像陈硕这篇BLOG说的,ACE很值得学习借鉴,但代码臃肿,有很多使用问题。
在重构后期,大家已经开始利用Trace本身进行调试。“吃自己的狗食”是个好现象。
建立Trace机制、升级Gcc消除Warning,都是为单元测试(Unit Test)和持续集成(Continuous Integration)做准备。自动化测试是我今年的重点目标。衡量一个团队有多精锐,不在于统计技术牛人的个数,而要看它是否拥有超出平均水平的制度 平台。我发现凡是不用版本管理(SVN、CVS或VSS均可)的软件开发组都很烂,甭管团队里有多少能工巧匠。前瞻研究实验室年度汇报,听到浩哥讲Godson-T的开发,他们就构建了很强大的自动化测试平台,让人不服不行。
还在考虑为pFind引擎构建“黑盒子”机制,把一段时间内的系统实时状态都记录下来,用以重现事故现场。云风做过类似的设计。不过这样一来,如何保证运行效率就成了关键问题。
这周很累,但有成就感。接下来折腾RCMS论文,19日deadline。大家的批改纷纷返回,多谢,汇总中。