开发记事本

生命中闪过了多少if...then...else...

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

公司的规模不大,做的项目不多,每个项目组的成员也少,最多的也就是四、五个人,目前的几个项目问题多多,各方面的问题都有,但是开发流程上的问题应该是最严重的。

这几天在考虑公司的开发流程可以做哪些改进,考虑的结果如下,自己的一点看法,如果有不合理的地方希望大家能给我指出来,帮助我改进,谢谢

公司现有开发流程改进可以做的地方

一、开发
1.开发时的模块划分不是简单的按照功能模块划分;必须按照面向对象的方法进行设计并拆分;

现在的划分方法是:按照程序的功能划分模块,基本信息给A做,库存管理给B做,业务模块给C做,报表模块给D做……

这种划分方法造成的结果是大家的开发是各自为战的,并且开发通常是面向过程的,程序很难进行自动化的测试;另一个就是代码的重用只能做到函数级的,对于一些业务逻辑的全面封装很困难;当然这些问题也跟开发工具有关,PB做OO开发要比做过程化的开发要困难。

模块的划分必须按照OO的概念进行,即必须把业务逻辑部分独立出来,这一部分必须是仅仅包含逻辑,而不考虑展现的问题;在其他的功能部分全部都是使用逻辑部分的功能进行数据处理;

这样做的好处是显而易见的:
1).代码的重用可以提高一级;
2).对于业务逻辑的修改可以封闭在业务逻辑部分,而对于展现部分的改动不会太大;
3).是在封装后的业务逻辑模块可以通过自动化测试工具(NUnit、DUnit等)进行单元测试,可以保证单元级的代码质量;

2.在开发过程中对业务逻辑部分使用测试驱动开发,要求对业务逻辑类必须先写出测试类,在开发过程中始终以测试对开发进行检验,以保证业务逻辑的正确性。

二、开发过程
1.开发过程必须使用配置管理系统,并且最好使用支持并行开发的SCM系统,比如CVS、SVN等;
2.对配置管理系统不能再作为单纯的源代码控制系统来使用,对于标签、分支等等功能都应该使用起来,这对于开发的管理是很有好处的;
3.推行每日构建,在每日构建后对业务逻辑部分进行自动化的单元测试,对于构建或测试失败的要立即解决,以免将错误拖延的太久,造成解决问题的代价过高;
4.Bug管理系统必须使用起来,目前使用Excel文件进行Bug管理的方法有诸多的缺陷,不是一个很好的办法;使用Bugzilla、Mantis等等Bug管理系统有助于对系统存在的问题进行跟踪管理,也有助于对开发过程的跟踪;
5.开发人员必须每天记录工作日志,工作日志不应该是单纯的是“今天做了什么模块,解决了什么问题”的垃圾信息,也不应该是给领导的工作汇报;工作日志更多的应该是大家在开发过程中遇到的问题、解决过程、心得等等的交流;我想通过建立一个内部的多人 Blog 用来记录工作日志比较好;

三、流程改进中存在的问题:
1.客户的需求总是在不停的变动,甚至在核心业务的流程上有有可能更改;对于这种需求变更无论怎样设计,其更改都不可能会少,需要想办法尽量减少这中需求变更对系统的影响;另一个就是在前期的需求调研中对用户的需求了解应该能够达到一定的深度,否则象目前项目在开发第二版的时候不得不推翻第一版的情况很有可能会再次重演;
2.系统必须有OO的设计,这方面大家的经验都很欠缺,而且欠缺的不仅仅是经验,更重要的还有OO的思想;
3.开发工具的问题,虽然公司在逐渐向VS.Net转移,但是目前大家比较熟的开发工具是PB,而且目前的一些业务项目仍然是CS结构,无法使用VS.Net开发;继续沿用 PB 则上面所说的全部都是一句空话;而如果改用Delphi,其转移难度仍然很大,转移的代价是否合算也是个问题;

posted on 2004-06-06 14:08  NetCobra  阅读(5126)  评论(14编辑  收藏  举报