最近接手一个新的任务:在公司产品的现有基础上做修补.面临的主要困难有:
1.项目较大,vs的解决方案里18个项目.(虽然我只须维护其中的一两个项目)
2.涉及新的技术,比如说多进程,多线程,网络通讯,wmi,adsi,iis,系统服务等等.
3.某些代码实现较复杂,如线程通讯,wmi等.这些函数的相互依赖,也就是平时说的藕合度高,现在我要将它分离,分到单独的项目里.但是这样又要求我对这些复杂的函数有正确的理解.不然一不小心就会出错,引来大量的bug就很可怕了.
根据以往的经验,我都会先看看这项目的框架,看看源代码,把整个软件理解一遍.
消磨了好几天,对项目有了大概认识,但每次看某些复杂函数的实现,总会有种力不从心的感觉.
问了几次坐在对面的小林,他跟我说这些已经是最简单的了.我不禁很心虚.
看代码真能消磨时间.我看啊看,终于,我慢慢地发现:针对某些模块做简单的测试是很好的办法.不再畏首畏尾,
不用怕fix掉一个bug又多了几个bug.测试结果便是最好的证明.
那些复杂的函数实现,在调试过程中看它的流程,能够更好的理解.
想到这里,我有种恍然大悟的感觉,为什么郑总要求一定要将wmi,adsi,实用函数分离开来,做成单独的模块.分离开来之后,看代码会舒服很多,更重要的是可以更方便的测试.做一个测试脚本,程序一跑,问题就都出来了.
软件测试,对于测试人员来说就是为了找bug,也是一切;对于开发人员来说,良好的设计也意味着有良好的测试用例.测试表面上看是更多的开销,但实现却是赚了大便宜.
都说全局变量不是个好东西.但是,就在几个月之前,我就做过一个软件使用了一定的全局变量,那时感觉真的很爽,都不知道给我省了多少麻烦,节约了多少时间.几个月后的现在,我就没有那么幸运了,看着别人做的一个工程,也就用了一个全局变量(是个struct),为了把模块分离开来.我不得不花大量的时间来看懂它的实现.真的挺痛苦的.从中我总结一条经验:
规模较大的工程尽量少用全局变量.
想明白后又发现这些道理都很简单,大学时老师们都说过N遍了,但是亲身体会真的不一样.