开发记事本

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

  博客园 :: 首页 :: 联系 :: 订阅 订阅 :: 管理
  57 Posts :: 2 Stories :: 278 Comments :: 10 Trackbacks

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

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

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

一、开发
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 阅读(4018) 评论(14)  编辑 收藏 所属分类: 开发心得

Feedback

#1楼  2004-06-06 16:06 鞠強      
1、dailybuild是很难作到的。没有充足的测试人员储备,你build完了之后谁来修改错误?谁来验证错误?建议你按照week build的思路来做。
2、妄图以OO的思想来设计业务系统,是非常难的。因为对业务的把握,我个人感觉比对程序思想的把握更难。
3、SCM过程中,最好不要使用分支功能,虽然很多工具都支持,但是对于你项目组的人员组成结构的划分,影响比较大。
4、bug跟踪,这是必须的。而且,是和SCM、dailybuild、testing结合的很紧密的东西。
  回复  引用  查看    

#2楼  2004-06-07 00:40 NetCobra      
谢谢鞠強。
1.DailyBuild我觉得还是必须的,DailyBuild并不是进行一种完全的测试,而是让计算机进行编译和基础性的自动测试工作,以保证源程序能通过最基本的检测,我觉得这应该是可以帮助开发人员减轻劳动强度,并且对代码质量有所保证;至于“build完了之后谁来修改错误”,问题出在谁身上,就由谁来改正,必须尽可能早地解决问题,如果因为测试人员储备不足就把错误延后解决,解决的代价只会越来越高;
2.“以OO的思想来设计业务系统”并不是“妄图”,我自己的体验,如果能够把业务逻辑独立出来,实际上对于系统中代码的重用能够有很大的好处的;
3.这一点我不太明白,分支功能对项目组影响在哪里?还请指教,谢谢。
  回复  引用  查看    

#3楼  2004-06-07 13:04 jiezhi [未注册用户]
你可以用过程的方法进行需求调研,分析和设计采用oo的方法。
至于开发流程,现在有这么多的成熟的流程,你完全可以借鉴。
  回复  引用    

#4楼  2004-06-07 13:08 NetCobra      
To jiezhi:
谢谢。
感觉需求调研过程没有什么过程化或者OO的区分,关键在于设计阶段对业务的建模过程。
成熟的开发流程很多,但是关键是要找到一种适合我们当前情况的方法,我上面写的这些基本上都是整队我们的当前状况设想的,主要是改进。
  回复  引用  查看    

#5楼  2004-07-02 12:00 dalian_siter      
你的问题很有普遍性,我觉得你的建议是好的,关键是,如何被贯彻。

有了好的想法,得有足够的资源来执行,包括:领导支持(百分之200重要,尤其是开发进度紧张的时候),技术储备,开发人员的支持,理解。

你可以试着去作,看看是否可行。
  回复  引用  查看    

#6楼  2004-07-04 12:04 ideage [未注册用户]
1.使用的工具是PB,也想过转入Delphi,C++,现在是VS.NET
2.流程是第一大问题,分工不好。正在学XP。
3.没有源码管理,现在有了CVSNT,仅可以管理数据库。
4.错误管理,基本是用一个wiki,天天更新。不太好用。
5.无法自动化测试,自动化构建,工作就是重复,现在试用NANT,NUnit,错误总要重复出现,修改了流程就要测试N天。
6.程序不大,用户流程总变,近来看了重构,发现方法还好,准备把PB的程序重构,将来重构成C#就OK了,OO也要一步一步的来。
7.VS.NET的不足:开发报表太麻烦(pb的dw快阿)水晶报表太庞大了。
8.人员管理,还没有好办法,基本就是不管。

  回复  引用    

#7楼  2004-11-25 10:48 NetCobra      
我倒,这篇文章竟然被选入“50篇精华文章 ”了,看来关注开发流程改进的人很多啊。

这篇文章是自己在做了4年的作坊式开发后的一点感想。原有的开发模式让大家做得非常的累,我很希望能够以自己的一点力量来推进公司开发流程的改进,至少可以把“作坊”做的正规一点,所以才会有这篇文章。

不过我失败了。

这篇文章发表在公司内部BBS上以后,没有收到任何回音,没有任何人和我讨论这些问题,我安装的Mantis Bug跟踪系统也很少有人用,VSS还是单纯的防止源代码互相覆盖而使用,大家所关注的还是能不能实现,而没有人去关心怎样能够更好地实现。

一个朋友告诉我,软件质量管理要自上而下的实行,也许是我太自不量力了吧?
  回复  引用  查看    

#8楼  2004-12-01 11:43 过客 [未注册用户]
ok, 我跟你情况类似,其实PB对OO支持非常有限,以PB工具的特点,以模块的划分应该是最简单的,在开发过程中也是比较容易控制的。当然有许多共通的东西是要抽取出来单独做了(包括逻辑和大部份控件组)。我接触的几个项目包括和东软合作的项目中都是采用的这个办法。
所以PB"感觉"是落后了,用它开发的公司越来越少,没办法,为了生存,我现在已经转行.NET和JAVA了。
但即使我现在这个公司用的是。NET,不过仍然是手工作坊式的开发,表面上用了什么ORM,CVS,NUNIT那都是摆设,连我这个才转入。NET的新手都感觉倒胃口,当然这公司开发都是小型项目,上头感觉不出来什么不好的地方,需求改了,拉上两三个人从后台到前台一口气一两天也就改完了。所以我觉得要想在项目中用上"先进"的技术手段和管理手段,要环境允许:(1头头觉得好,2负责技术的"认为"必要,3程序员理解用这些的好处)
现在有空就自己学吧,有机会就到一个正规一点的地方去
  回复  引用    

#9楼  2005-02-13 13:34 rampig [未注册用户]
典型的无序的软件开发项目
问题的根源在于:
将系统分析变成了工程分包。

还有就是只会用OO术语的、思想简单的、理想化的程序员。

阿门。

上帝保佑中国软件。

  回复  引用    

#10楼  2005-08-07 15:55 smilefox [未注册用户]
公司现有开发流程改进可以做的地方 2004-06-06 16:06 鞠強
1、dailybuild是很难作到的。没有充足的测试人员储备,你build完了之后谁来修改错误?谁来验证错误?建议你按照week build的思路来做。
....=============

dailybuild 我们公司做到了,嘿嘿,测试与开发的比例是1:1.
我们把单元测试放在了dailybuild中,而且build完成后马上又会有BVT测试(必须是自动化的),头说我们要向微软的测试看齐,我们基本朝着这个方向前进。
公司虽小,但上上下下都对质量很重视。
  回复  引用    

#11楼  2005-09-21 12:20 weiwoo [未注册用户]
中午休息,看到这篇文章,觉得很好。也因为有这么多人关注开发问题。
没有太多的经验,前段时间看书上说的。
1。开发手法
大的系统开发都用waterflow。占当前开发的70%,
大的软件公司甚至有开发辅助系统,就是项目经理根据项目内容回答辅助系统的问题,最后辅助系统从数据库中选出最合适的开发管理模式,据说有的公司具有400多种可先模式。
2。反复开发
现在大家都面向的开发手法。占开发的从8%长到了20%,并且将来有和waterflow并驾齐驱的趋势。
这个开发手法主要是对应客户要求的不断变更。但,要求各个环节都有个标准,以防止无限度的开发或是无限度的测试。
3。敏捷开发法
对于小的项目,采取的开发方式。由客户人员,设计者,编程人员组成小组,开发工程中,不断讨论。在小的开发项目中取得了很好的效果。

都是看来的,自己也不懂。

  回复  引用    

#12楼  2005-09-30 11:23 manager [未注册用户]
需要实践,因地制宜;我现在的处境和你一样的,完全是在赶项目,把回款拿到。
合适的才是最好的,先进的思想、工具一堆一堆的,什么才是最适合的呢?这是最重要的;
随着项目的积累,会好起来的
关键是不要轻易放弃,而是要不断思考、改进
  回复  引用    

#13楼  2005-10-11 17:34 g [未注册用户]
看看这个项目管理系统(PYTHON开发;有源代码)
主要用来管理项目事务信息/BUG管理,用了用,挺方便的,而且开放了最新的源代码。
http://www.ridow.com/product.html
  回复  引用    

是的,很关注开发的流程——确切说是过程,包括效率和质量。
  回复  引用