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

被折叠的 条评论
为什么被折叠?



