如何提高软件质量?

zhoujia83
能做的事,应该做的事,其它的我无法改变 2010-07-07 字数 153

最近兼任项目组长,郁闷的发现团队开发的C#软件一塌糊涂

联调起来错误百出,而且每个bug都要花很长时间才能找到

大侠们救救我,怎么样才能提高项目组的软件开发质量?

DotNET Microsoft.NET技术
22 个回复
SPWaistcoat
clear 2010-07-07

有单元测试吗

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 最近兼任项目组长,郁闷的发现团队开发的C#软件一塌糊涂

: 联调起来错误百出,而且每个bug都要花很长时间才能找到

: 大侠们救救我,怎么样才能提高项目组的软件开发质量?

: ...................

zhoujia83
能做的事,应该做的事,其它的我无法改变 2010-07-07

没有。。。属于敏捷型团队,4个人开发,一个测试人员。

开发时基本只图尽快把功能实现了,不太注意稳定性

【 在 SPWaistcoat (  ) 的大作中提到: 】

: 有单元测试吗

zhoujia83
能做的事,应该做的事,其它的我无法改变 2010-07-07

我自己总结了几个原因,不知是不是关键原因:

1、开发人员编程素质较低,责任心不够

2、对于重要方案和逻辑考虑不全面,留下隐患

3、缺少单元测试,缺少监督

我想到的几个解决方法

1、项目组长强调编程质量,对代码进行抽样审查,程序质量作为考核指标之一

2、对于重要方案和逻辑,开会讨论,并形成文字

3、增加单元测试

4、增加程序监控模块,对重要调用、网络收发消息进行实时输出

请大侠指点。

【 在 SPWaistcoat (  ) 的大作中提到: 】

: 有单元测试吗

oldwatch
一条叫java的鱼◎城内风光独好 2010-07-07

别糟蹋敏捷这个词行不?

这叫赶工团队

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 没有。。。属于敏捷型团队,4个人开发,一个测试人员。

: 开发时基本只图尽快把功能实现了,不太注意稳定性

zhoujia83
能做的事,应该做的事,其它的我无法改变 2010-07-07

有很多以前的代码,算是历史问题

【 在 oldwatch (一条叫java的鱼◎谷歌将死,高墙早立) 的大作中提到: 】

: 别糟蹋敏捷这个词行不?

: 这叫赶工团队

graceman
过眼云烟 2010-07-07

1、开发人员编程素质较低,责任心不够

第一点就很致命了

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 我自己总结了几个原因,不知是不是关键原因:

: 1、开发人员编程素质较低,责任心不够

: 2、对于重要方案和逻辑考虑不全面,留下隐患

: ...................

zhoujia83
能做的事,应该做的事,其它的我无法改变 2010-07-07

现在我也不能换人,只能改变他们了

【 在 graceman (过眼云烟) 的大作中提到: 】

: 1、开发人员编程素质较低,责任心不够

: 第一点就很致命了

hbifts
You're beautiful, it's true 2010-07-07

先把屁股擦干净:

视情况,花时间,按模块的重要程度、bug密度、优先级等,重做单元测试。

其代码的覆盖率要达到90%以上。

再把规定定下来:

ut、code review

再加上 持续集成

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 现在我也不能换人,只能改变他们了

graceman
过眼云烟 2010-07-07

很多人看两眼C#语法就动手写,遇见这样的人,真要要求质量的话,就难了

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 现在我也不能换人,只能改变他们了

thss2003
thss 2010-07-08

我想知道如果分工的?

也就是如何分模块.

最后怎么样把每个人的代码组织在一起?

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 最近兼任项目组长,郁闷的发现团队开发的C#软件一塌糊涂

: 联调起来错误百出,而且每个bug都要花很长时间才能找到

: 大侠们救救我,怎么样才能提高项目组的软件开发质量?

oldwatch
一条叫java的鱼◎城内风光独好 2010-07-08

既然已经号称是模块了

终归是有明确接口分界,可以挂单元测试的

【 在 thss2003 (thss) 的大作中提到: 】

: 我想知道如果分工的?

: 也就是如何分模块.

: 最后怎么样把每个人的代码组织在一起?

: ...................

jehovah0121
Largest Loser 2010-07-08

原来敏捷是这个意思。。。。

我觉得吧,如果开发的时候只图实现基本功能,那联调的时候必然是这种状况。

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 没有。。。属于敏捷型团队,4个人开发,一个测试人员。

: 开发时基本只图尽快把功能实现了,不太注意稳定性

ggmail
no way 2010-07-08

只能说明没设计好

如果设计好了

开发是按照设计书来开发的

还能错误百出???(出也是设计的问题了)

其实我猜,几个人的mini项目,估计都没设计

直接上来就开发了

【 在 zhoujia83 (能做的事,应该做的事,其它的我无法改变) 的大作中提到: 】

: 最近兼任项目组长,郁闷的发现团队开发的C#软件一塌糊涂

: 联调起来错误百出,而且每个bug都要花很长时间才能找到

: 大侠们救救我,怎么样才能提高项目组的软件开发质量?

: ...................

oldwatch
一条叫java的鱼◎城内风光独好 2010-07-08

不能排除糟糕的设计比没有设计还难对付的情况……

【 在 ggmail (no way) 的大作中提到: 】

: 只能说明没设计好

: 如果设计好了

: 开发是按照设计书来开发的

: ...................

keygen
失落灵魂之囚 2010-07-08

如果开发能按照设计书翻译,那设计的时间也会大大增加。

【 在 ggmail (no way) 的大作中提到: 】

: 只能说明没设计好

: 如果设计好了

: 开发是按照设计书来开发的

: ...................

equbuaa
哼哼 2010-07-08

开发人员理解的模块,可能耦合性和强,特别是在开发人员水平不高时,在coding的时候一般都不会考虑到可测试性。

建议加大联调强度,大家一起走业务,有问题,是谁的问题谁更改。

底层模块让一个水平高的统一一下(例如:数据库访问,网络通信,报文编解码,UI风格、业务类定义等),然后针对底层先开始单元测试。

最后,一定要淡定,不要着急,既然要在一起工作,大家开心是最重要的。

【 在 oldwatch (一条叫java的鱼◎谷歌将死,高墙早立) 的大作中提到: 】

: 既然已经号称是模块了

: 终归是有明确接口分界,可以挂单元测试的

oldwatch
一条叫java的鱼◎城内风光独好 2010-07-08

我一直很推崇单元测试的一个重要原因就是:

单元测试会逼着你写出低耦合的模块接口

因为如果耦合太高了,你根本就无从下手写单元测试用例……

很多时候,自己写接口时还没感觉

等到写testCase时就觉得怎么写怎么别扭,最后老老实实回头去重构

【 在 equbuaa (哼哼) 的大作中提到: 】

: 开发人员理解的模块,可能耦合性和强,特别是在开发人员水平不高时,在coding的时候一般都不会考虑到可测试性。

: 建议加大联调强度,大家一起走业务,有问题,是谁的问题谁更改。

: 底层模块让一个水平高的统一一下(例如:数据库访问,网络通信,报文编解码,UI风格、业务类定义等),然后针对底层先开始单元测试。

: ...................

graceman
过眼云烟 2010-07-08

只是有时候解耦太麻烦..

【 在 oldwatch (一条叫java的鱼◎谷歌将死,高墙早立) 的大作中提到: 】

: 我一直很推崇单元测试的一个重要原因就是:

: 单元测试会逼着你写出低耦合的模块接口

: 因为如果耦合太高了,你根本就无从下手写单元测试用例……

: ...................

equbuaa
哼哼 2010-07-09

是啊,好像无论是国标还是军标,都强调甚至在需求阶段,测试就要介入。

但在实际项目中,因为资源有限,往往没有可测试性的约束,导致出现耦合性很强的代码。

没办法,很多东西都是走了一轮后,大家才认识到的。

【 在 oldwatch (一条叫java的鱼◎谷歌将死,高墙早立) 的大作中提到: 】

: 我一直很推崇单元测试的一个重要原因就是:

: 单元测试会逼着你写出低耦合的模块接口

: 因为如果耦合太高了,你根本就无从下手写单元测试用例……

: ...................