项目升级　回顾总结

项目升级　回顾总结

这一年多主要做了两个完整的项目．并且都是从ｖｂ升级到ｖｂ２００５．ｎｅｔ的。项目过程中的一些事情想做个总结，主要是对项目中的注意事项做一个全面的回顾，也算是留个备份。

（一）项目基本说明
整个项目开发目的是把原来用ｖｂ写的代码，翻译（或者叫升级）成ｖｂ．ｎｅｔ的代码。当然其中某些功能会有稍微的改动，但基本改动不大。项目开始时，手头的资料只有原来程序的ｖｂ源代码和最原始的画面迁移图，图上带有简短的功能说明。开发人员，２－３个人，开发时间４－５个月。

（二）项目开发过程如下：
１：前期准备过程
项目开始了，就手头仅有的资料，咋办？翻翻画面迁移图，看不出啥东西来。幸好老代码还可以运行，跑跑画面，调试调试源代码，对比着图和说明大致了解了解程序的功能，过了两三天，觉着理解的差不多了。这时，领导说需要写详细设计书，那就开始写详细设计书吧。５０多个画面，一边对比着源代码，一边跑跑画面，在自我理解的基础上，经过近一个月的努力，详细设计书终于完工了。完工了是完工了，可是对于程序的整体功能以及具体实现细节还是含含糊糊，纯粹是个人的理解，到这个时候为止，每个人到底能理解多少，谁也没有数，毕竟仅从代码阅读中理解的信息还是有限。最终详细设计书中体现的只是每个画面的控件定义，事件定义，以及大体的逻辑处理流程。

２：编码
接下来开始编码，项目经理基本上什么都不管，或许只是挂个名，只有业务上有困惑的时候才找他咨询。他想要的只是最终的产品，至于如何开发，怎么方便怎么来，呵呵。所以，开发环境的搭建，程序框架的构筑就基本由我来主刀了，即使我只会用小刀，也只好硬着头皮。参考老代码，一部分一部分把共通的部分抽出来，再把页面按照功能分分类，然后每个人分一部分模块，给大家讲一讲现在的框架和共同，就开始编码了。编码的过程，就是比着老代码，改成新代码。ｖｂ与ｖｂ．ｎｅｔ的区别就是更改的主要对象。当然框架有所变化，老框架适应新框架的地方也要注意。
稀稀拉拉，一边编码，一边对小功能模块进行简单的单元测试，不算忙，大约两个月左右，终于把代码写完了。老代码中的功能模块在新代码中都有了。比较有成就感，呵呵。不过，其实，这个时候的程序，仅仅是用新代码把老代码写了一遍，可能大的逻辑流程没有问题，但细节的问题都潜伏在其中。肯定地说，远远不够。

３：集成测试
这次，项目组人员变动了，这一部分由我一个人来弄。以自我意识为主导，从界面到编码都进行了一遍扫瞄。跑跑各个画面，用简单的数据测试一下模块间的接口，大约花费了两周时间。一些面上的问题和浅层次的逻辑问题基本上在这个过程中得到解决。但用时太少，并且没有大量数据的测试，残留的问题还是很多。

４：综合测试
这个时候，项目经理把老的数据给整来了，导入新系统中，好了，现在开始比较。每个画面的标题文字，窗口大小，初始化时光标位置，按钮的动作，逐一比较，不一致的地方是为什么？对比代码找原因，是原来老系统的问题还是我们的问题？该向项目经理请示的请示，该确认的确认，改！有打印功能的模块，都打印出来，对比两份输出文件，格式？！数据？！就这样一个半月过去了。忙得团团转，修改了无数的问题，最终加班加点交了工！心想问题真多啊，心里开始忐忑不安。

（三）数据分析（以最近一次为数据依据）
１：代码分析：
文件总数　３８６
总行数　６１６７３
空行　７５７０
注释行　８２５３
有效行　４５８５０
按５‰的ＢＵＧ率算　应出ＢＵＧ＝４５８５０＊５‰＝２２９．２５

２：用时分析：
前期准备过程（含详细设计）　１个月
编码／单元测试　２个月　没有统计全面的单元测试，粗略估计１００－２００
集成测试　０．５个月　ＢＵＧ数：７６（界面：３３）
系统测试　１个月　ＢＵＧ数：４８（界面：２７）
项目预计用时　１０８人日
实际工时　１６７．４人日

３：ＢＵＧ类型分析：
界面　６０
逻辑　６４
合计：１２４

（四）项目总结
整个项目结束了，回过头来看一看，哪些地方做得不够，有没有需要改进的地方。
通过以上统计分析，主要问题在于集成测试和系统测试时ＢＵＧ数比率不太协调，比较乐观的比率应该是　系统测试／集成测试＝１／３左右，个人认为。还有就是界面的问题太多，系统测试时竟然有近一半的问题是界面大小，文字格式，光标等。这说明，前面的单元测试和集成测试做得远远不够。
其实，现在回想一下也是，在编写代码的时候，基本上对老代码业务逻辑的理解程度只能算是一知半解，只是在机械的翻译代码，连带了解一些业务。自己的模块做完了，仅用简单的数据测试了一下，就草草的进入了下一个功能模块的编写。集成测试的时候，本来主要是为了测试各个模块间的协作的，不会花大量时间精力去进行某个模块数据对比和测试，所以有些逻辑问题就得不到解决，最终全都留给综合测试了。
或许整个项目过程中综合测试这个过程是最累的，加班加点。问题一堆一堆的被揪出来，有界面的问题，也有逻辑处理的问题，有个人疏忽的，有理解不充分的，也有原来老系统的ＢＵＧ遗留下来的。总之是什么样的都有。自信心是受到了不小的冲击，马上就要纳品了，问题还这么多，呵呵。所以就开始感叹了，前几个过程怎么走的？问题怎么还这么多？但没办法，该改的还是要改的。需要冷静！需要冷静！
项目中时间把握的不知是不是理想，虽然超了近６０人日。因为不知道他们是如何估算的，反正项目没有延期，项目中加班也不多，这先不考虑。

（五）需要改进的地方
基本过程还是这样走，但是有几个地方要注意
１：编写代码时，基本实现流程力求和老系统一致，老系统中有的代码，在新系统中一定要有所对应。除非你对老代码整体有很好地把握，除非你经验非常丰富，否则不要轻易按自己的想法来改代码，尤其是刚毕业的新人和编码经验匮乏者。这一点尤为重要。当然，由于框架的不同，开发语言不同，以及老代码处理逻辑的烦琐等等的原因，有些地方必须重新安排逻辑处理，这时一定要小心谨慎，深思熟虑。

２：代码回顾（ｒｅｖｉｅｗ），这个很重要大家都知道，有时候自己看半天愣没发现什么问题，让别人一看就能给指出来。开发前期，对于统一代码风格，减少同类错误出现的几率，非常重要。

３：单体测试时，一定要把新画面和老画面进行对比，最好做个ＣｈｅｃｋＬｉｓｔ，每一项都要自己测试到。有对比，才能有所区别，这一步做好了，估计到最后综合测试的时候就不会还有那么多界面的问题了。在注重逻辑流程和数据正确性测试的同时，错误测试也同等重要。有些开发人员，编码完毕，输入一个正确项目测试一下，发现对了，就撂摊子，接着进行下一个功能去了。 开发进度是很快，但代码健壮性却被忽视了。
（ＯＶＥＲ）