免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12345下一页
最近访问板块 发新帖
查看: 15215 | 回复: 43

[讨论]大家来讨论一下开发流程问题 [复制链接]

论坛徽章:
0
发表于 2002-09-29 16:34 |显示全部楼层
其实我不想讨论软件开发的流程到底是什么样子的,因为流程谁都知道,也会制订,但是当任务特别紧的时候还能按找规范的流程来走就不容易了,所以想问问大家都有那些好的经验,咱们讨论讨论。

论坛徽章:
0
发表于 2002-09-29 18:00 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

我现在学习使用 xp (eXtreme Programming 极限编程)的过程。说明如下:

和用户讨论需求,把系统分成一个一个的 user story,每个 user story 代表系统的一个功能。

然后和用户讨论各个 user story 的优先级。优先级高的先做。

按一个到两个月为一个 iteration。把优先级最高的几个 user story 做完后。发布一个 release(一个真正的 release,不是 beta)。拿给用户看,让他们提出意见。

再根据用户反馈的意见调整 user story,和系统结构,继续下一个 iteration。

这种方法很适合小规模开发,和时间特别紧的情况。可以让用户最早的获得最需要的功能。

论坛徽章:
0
发表于 2002-09-29 20:26 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

听说过这种方法,的确挺节约时间,不过似乎只是适合中小项目,对于大型项目尤其是内聚性比较强的似乎不太适合,而且看上去不太符合软件发展的潮流

论坛徽章:
0
发表于 2002-09-30 09:19 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

相对于重量级的编程方法uml等而言,极限编程称为轻量级的方法,在很多人看来还很新。下边是为大家提供的一些参考资料:

http://www.agilechina.org/extremeprogramming/index.html

http://www.agilechina.org/

http://www.csdn.net/subject/125/

论坛徽章:
0
发表于 2002-10-06 13:18 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

[这个贴子最后由cinc在 2002/10/06 01:21pm 编辑]

呵呵,内聚性比较强是什么意思啊?

为什么说 XP 不符合潮流呢?

软件开发的技术发展几十年了,经历的好多种开发方法,面向过程的到现在的面向对象
的,也不知道面向对象的技术能领导潮流多久,但软件开发中有一个元素永远在起作用:
代码。编写代码这个活动永远在各种方法中占有一席之地。

在一个软件产品中,最重要的是什么呢,我觉得是软件的质量,而软件的质量的最终体
现是在代码。 write perfect code,就是 xp 的一个目标。XP 非常看重代码的质量。
任何有助于提高代码质量的实践都是 XP 提倡的,而且 XP 把这些实践推向了极致,所
以我们称之为极限编程:

摘自 http://www.xpchina.org/
----------------------------------------------------------------------------------
kent beck说了,如果一件事情好的话,那我们就走极端,让每个人、每时每刻来做,
意思就是极端化,把好处最大化,其他的解释都不通:
So why the "extreme" in the name? XP takes commonsense principles
and practices to extreme levels.
   
1.If ... are good, we'll .... all the time.
2.If .... is good, everybody ..all the time.
3.If ....is good, ...everybody's daily business
4.If ..is good, ...always..
5.If ... is important,everybody.....all the time.
6.If ....is important,..several times a day
7.If .. is good,...realy realy short-seconds and minutes and hours...

结对编程:
if code reviews are good,we'll review code all the time ---pair programming

单元测试:   
if testing is good,every body will test all the time ---unit test
我们使用 JUnit 做 Java 的单元测试,用 CppUnit 做 C++ 的单元测试

功能测试:   
even the customer ---functional testing
用户自己写测试

重构:   
if design is good,we'll make it part of everybody's daily business ---refactoring

简单设计:
if simplicity is good,we'll always leave the system with the simplest design
that supports its current functionality
---the simpliest thing that could possibly work

隐喻:   
if architecture is important,everybody will work defining and refining the
architecture all the time ---metaphor

持续测试:   
if integration testing is import,then we'll integrate and test several times a day
---continuous integration

小版本发布:   
if short iterations are good,we'll make the iterations really,really
short--seconds and minutes and hours ,not weeks and months and years
---the planning game
   
愿意的确是把这些好的要素强调到极点,不过翻译成极限也很不错,xp还在继续发展和演化中,
取其“无极限”的意思吧。
   
----------------------------------------------------------------------------------

上面提到的这些都不只是理论,已经有相应的工具可以支持:

单元测试:   
  XP 规定必须先写测试,才能写代码。
  我们使用 JUnit 做 Java 的单元测试,用 httpunit 做 servlet 测试,
  JUnit 已经集成到 JBuilder 和 VisualAge 中了。
  用 CppUnit 做 C++ 的单元测试,
  XUnit 是他们的总称。
  http://www.xprogramming.com/software.htm

持续集成测试:   
  在 java 下我们使用 Ant 来做持续集成,Martin Flower 曾经写了一篇文章:
  http://www.agilechina.org/MartinFowler/continuousintegration.htm
  XP 中有个口号叫“拥抱变化”,就是承认需求永远是在变化的,所以我们能做的就
  是让他将来变化的时候对我们的冲击最小。完整的单元测试 junit 和 集成工具 ant
  使我们对将来需求和代码的任何改动都充满信心。

重构:   
  除了理论 ( Refactoring: Improving the Design of Existing Code by Martin Flower)
  已经有工具来实现里面的功能:
    IntelliJ  IDEA 最出名。
    还有的 rafactor 工具已经集成到 JBuilder 中了。

集体代码所有权:
  我们使用 CVS 管理软件的版本。


XP 的理论就像一个洋葱,最外面是过程,中间是团队实践,而最里面,也是最重要的
就是编程,任何软件开发都回避不了的问题:code。外面两层的目标也是为了写出高质
量的代码。

可能由于 xp 从比较细节的角度考虑软件开发的问题,现在还只是适合小规模的开发。
但他里面的一些方法和实践同样值得大规模软件的参考。

论坛徽章:
0
发表于 2002-10-07 02:15 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

讨论后,我发现大家又跑到代码上来了,而且这位cincs说,永远不变的是代码!?真的吗?
我认为不是,最重要的是需求!对需求的正确和完备理解,将大量的减少工作量。什么面向对象,什么面向过程,不过是在需求的理解之上,将组织,人员和业务比作什么的问题。
最快的办法,
1.就是不断的和客户讨论需求,一定要客户仔细的说出他现在能够描述的需求细节;
2.就是对于业务的熟悉,在统一的行业规章下,对业务的熟悉将加重你对需求的实现在客户心中的地位&#59;
3.当然,正确的划分模块,将有利于需求的修正。实现时,根据你的业务经验,考虑客户可能做的修改;
4.边开发,边测试;人员分配在这里就显得很重要,写代码不需要很多人,需要的精华,是有着开发产品和熟悉业务的程序员完成;将不熟悉的人(特别是对业务熟的)分配到测试中,还有你也要在测试组。
我的经验,可能不成熟,大家见笑了。

论坛徽章:
0
发表于 2002-10-08 14:32 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

软件的质量就是代码?那么,由此推论,使用好的建筑材料就一定能盖起好的建筑了?

如果一个项目,程序员都非常优秀,写出的代码都是一流,但是却忽视软件结构的设计,
这样的软件还能算好的软件吗?

按照XP的做法,如果,把一个系统分成许多user story,孤立的去实现,必然会降低系统的内聚性,
除非这个系统的各个user story真的毫不关联,但是这样的系统毕竟是少数。

所以,XP方法至少在这一点上是有问题的,当然,有一种情况例外,那就是,你在
做一个项目的时候,这一类型的应用你已经非常精通了,你可以分成若干user story,
但是前提是要在设计的时候充分考虑到今后的后续设计开发(因为这是你可以作到的)。



论坛徽章:
0
发表于 2002-10-08 18:17 |显示全部楼层

[讨论]大家来讨论一下开发流程问题

[这个贴子最后由cinc在 2002/10/08 06:20pm 编辑]

我接触 xp 不是很久,自己也还在摸索阶段,对有些概念的理解还不是很透彻,有些还不是很清楚。
希望和大家一起讨论。呵呵

首先澄清下,好的代码的标准是:
    完成用户提出的功能,简洁易懂的代码。没有重复代码,好的系统结构,每部分代码都有测试代码相伴。

关于设计时充分考虑到以后设计的问题:
  XP 中有个 small release 的概念:把整个系统的开发过程分割为一个一个 iteration。每个
  iteration 实现几个用户认为最有商业价值的功能(就是user story)。由于范围的缩小,一
  个 iteration 只有几个 user story ,所以可以让开发人员集中精力做好这几个功能。使系统
  模块化。
  XP 的一个原则是 make it simple ,不考虑太多将来的事情。就是做好现在需要的,明天
  的事情明天作,今天的事情要做好,这里的简单就是刚刚好的意思 就是你做的东西刚好满足
  客户和你自己现在地要求 而不是以后可能会发生的要求。谁知道用户将来会想什么。你为他
  考虑的未必将来用的到。

  XP 认为:需求永远是变化的,所以 XP 只考虑现在的事情,但不代表 xp 不为将来做打算。
  在将来需求变动的时候,完整的test ,优秀的代码,使开发人员能自如的应付这些变化

>;软件的质量就是代码?那么,由此推论,使用好的建筑材料就一定能盖起好的建筑了?
>;如果一个项目,程序员都非常优秀,写出的代码都是一流,但是却忽视软件结构的设计,
>;这样的软件还能算好的软件吗?
其实 xp 是很注重系统结构的。但 xp 推荐的分析工具是 CRC( class Resp) Card。
对一个 user story,让所有开发人员坐在一起分析(这样做的目的是让开发人员对系统
有个统一的认识),分析结果用 CRC Card 表示,并把任务分解成一个个 task。然后开
发人员每次拿一个 task 去实现。

>;按照XP的做法,如果,把一个系统分成许多user story,孤立的去实现,必然会降低系统的内聚性,
>;除非这个系统的各个user story真的毫不关联,但是这样的系统毕竟是少数。
user story 中描述的是用户希望系统实现的一个个功能(feature),是从用户角度的看系统。
实现一个 user story,可能要修改的地方会遍历整个系统的各个部分。所以 user story 的划分和
用户的系统的内聚性应该是没有关系的。在实现 user story 时也是会做分析设计的。

XP 中的设计,不是对整个系统的分析,而是把系统分成几个小部分后对每个部分的分析。
XP中也强调planning,但不是说要把一个系统大而全的设计好才开始工作。而是说针对
一个最简单任务单元( story or engieering task )做仔细的考虑,就是"三思而后行"。

呵呵,我可能把代码看的太重了,但是对 xp 来说,代码确实是很重要的。

论坛徽章:
0
发表于 2002-10-08 19:03 |显示全部楼层

[讨论]大家来讨论一下开发流程问题


但是问题恰恰就出在这里,一般的观点是(特别对于大型软件),一个软件系统中,代码恰恰是最不重要的(但不是不重要,只是相比较而言),因为一个系统设计好坏的标准之一就恰恰是代码容易编写。

还有,只是简单的实现用户现有的功能在很多情况下是不够的,更何况很多情况下用户自己都不知道到底要实现什么功能。而且在不对应用系统进行全面的系统分析的情况下就进行设计,设计的系统很难保证将来在其他功能加上的时候系统的健壮,虽然强调在做设计的时候要“三思而后行”,但是毕竟只是纸上谈兵,在遇到不同的情况时,特别是复杂的情况时,只能依赖与开发者的智慧,缺乏可控性。

所以,我认为,XP只能在特定的条件下使用,只能作为一种思想,一种经验,但很难成为一种规范或者方法

论坛徽章:
0
发表于 2002-10-09 00:09 |显示全部楼层

[讨论]大家来讨论一下开发流程问题


xp 的一个好处就是通过把范围缩小,来一步一步解决大的问题,小的系统比大的系统来的
更容易设计和实现吧,xp 通过缩小范围来实现良好的设计。而且这个叠代的过程也可以让
用户获得最大商业价值,最快的用户反馈。

用户不知道他们实现的功能,很好啊,这正是 xp 所擅长的,XP 的方法是很注重反馈的:
先让用户把想象中的系统描述出来,我们实现他最需要的几个功能,短时间的 iteration
得出的是一个包含用户想象中最需要功能的可以运行的版本,马上拿出一个可以用的软件
让用户使用(让用户对最终的程序提出意见比让用户对前期的设计提出意见不是更好吗?)
,这样用最短的时间得到用户的反馈,再根据这个反馈做修改。传统方法要对整个系统经过
分析设计,编码,测试,得到反馈的周期不是更长吗?


如何保证将来在其他功能加上的时候系统的健壮:
  我觉得传统方法和xp 的做法都是为了这同一目的,但做法不一样:
  传统方法:旧方法提倡对将来的修改尽早(尽量在设计阶段)做好准备,使用到的技术有
  模式,是前瞻性的一种做法。有个问题,设计什么时候算是结束呢?设计结束后需求再变
  化怎么办呢。
  而 xp 面对需求的改变靠的是勇气,但不是蛮干,他是这样做的:
   设计级别:简单为主,能实现功能的代码就是好代码。当以后发生变化时,用设计模式的
     知识和其他经验对现有的代码进行 refactoring,得出更好的设计,结果也和传统方法
     一样。refactor是对已经运行起来的代码的结构的优化,里面运用到了模式的知识,和
     前人的经验。
   代码级别:设计系统结构时,我们也用面向对象的方法思考:针对接口编程,模块内紧耦合,
     模块间松耦合,遵循相关的代码标准,等等。而且由于测试先行,我们对每一部分代码都
     有测试代码。所以我们不害怕代码的修改。在一个 refactor 后,我们再次运行所有的测
     试代码,如果测试出错,错误一定就在刚才修改的地方,范围缩小了,差错也容易多了。
     所以 xp 的系统设计出来的代码也是很容易编写,很容易理解,很容易维护的。

对于 refactor ,有一本书叫 Refactoring: Improving the Design of Existing Code
透明和侯捷先生正在把它翻译成中文:http://gigix.cool2u.net/
我们并不是没有理论基础的,也并不是只能依赖与开发者的智慧,不管怎么说,传统方法和xp 都
是需要经验的,有些经验是可以学来的,有些也只能靠实践中摸索学习,是吧。呵呵

XP只能在特定的条件下使用:
  确实如此,但这个是指项目中参与的人数,而不是项目本身的规模。
  关于 xp 在项目中的应用,基本上是在 10人到20人的项目中,便于沟通。
  xp 强调所有开发人员对系统都基本有一个统一的认识,这些人中没有特别说谁是分析员,谁是
  写代码的。分析一起做,代码大家共有。如果大于 20 人,开发人员之间的沟通就成了一个很
  大的问题。在这样的项目组里只能实现修改了的 xp 的方法。

至于说 xp 是不是规范或者方法,很难下定论的,软件业刚刚起步几十年,每个方法都有自己领先
的地方,都有他适用的领域,而且都在发展,谁也说不准过十年会是什么方法流行起来。

xp 中的这些方法都不是凭空产生的,有些也是从传统方法中学习过来的,有的只不过换了一个说法
而已,比方说 refactor 也可以说是设计模式的另一种应用。

呵呵,说了很多,不对的地方欢迎指正。


您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP