Binormal

The genuine programmers use C++

 

反驳极限编程的四点理由

接触极限编程一段时间,找到以下四点反驳它的理由:
[1]代码质量
极限编程运用测试驱动开发(TDD),其理论基础是需求应该是可测试的,其目的在于保证软件系统的正确性和健壮性(测试用例足够充分的话)。可以这么认为:极限编程关心的是结果,不关心过程。因此它忽略了软件系统的结构性和开放性。我们知道结构性有助于修改,开放性有助于扩展,而极限编程却放弃这种追求,导致的结果就是产生一大堆丑陋的代码,而且随时有可能被彻底抛弃。
极限编程解决效率,结构性和开放性问题的对策是重构,它宣称重构无处不在,但是重构是一种补救的方式,为什么不在设计初期进行预防呢?极限编程回避不了这些问题,而只是将它们推到了后面的阶段,但是付出的代价可能会更高。
[2]工作进度
极限编程直接将代码作为文档,弱化传统文档的作用。既然如此,那么代码就应该有规范的格式和详尽的注释,以便提高它的可读性,但是由于极限编程采用的是团队合作方式,代码规范很难得到统一。那么通过注释吧,可是极限编程认为注释是一种负担,无法适应频繁修改的代码。
极限编程解决沟通问题的对策是结对编程,它认为频繁的沟通胜过面面俱到的文档,但是文档是永久的,沟通却是短暂的,大家可以看同一份文档,却要进行多次两两沟通,所需时间也许并不比写文档的时间少。更糟糕的是,经常地切换搭档将极大地破坏工作的延续性,只能拖慢进度。
[3]工作量
测试驱动开发具体应该怎么做呢?测试驱动决不是说代码从测试写起,在写测试用例之前,肯定要对需求有完整的了解,否则测试无从写起,其实这就是需求分析以及设计,还是与瀑布模型一样的流程,只不过没有文档化而已。唯一不同的是极限编程要求需求都是可测试的,因此要把这些需求翻译成系统测试用例,集成测试用例,和单元测试用例。由于写程序必须同时写它的测试,因此如果改程序则必须改测试,这将达到两倍的工作量。
[4]目的
极限编程认为需求是不断变化的,因此软件能满足当前需求就好,没有必要构造框架之类可复用的东西,它认为这是一种过度设计。这种思想是极端的,因为框架就是为了解决需求变化问题而出现的。举个例子,MFC就是一套框架(尽管我厌恶它),但是基于MFC却可以开发网络,多媒体,数据库甚至游戏应用程序。面向对象的目的就是为了复用,而且好的框架能够做到隔离变化,依赖抽象,如果认为软件系统的一切东西都是暂时的,无疑是与面向对象思想背道而驰的。

posted on 2007-07-07 16:08 Binormal 阅读(693) 评论(11)  编辑 收藏 引用

评论

# re: 反驳极限编程的四点理由 2007-07-08 01:11 eXile

呵呵, 自从我知道了XP以后, 立刻就喜欢上了它, 肯定也有人不喜欢它.这是正常的. 选择你喜欢的开发方式就对了. 不过你对XP的认识存在几个明显的误区, 这些在XP的书里已经说得很清楚了。说实话,你所说的有几个理由,使我甚至怀疑你是大学里面讲软件工程的教授,夸夸其谈,但是和实际脱节。  回复  更多评论   

# re: 反驳极限编程的四点理由[未登录] 2007-07-08 19:28 shilei230

这些观点是我在公司经过三个月的实践之后得出的总结,所提及的问题问题都是存在的,阁下有何高见不妨赐教!  回复  更多评论   

# re: 反驳极限编程的四点理由 2007-07-08 23:49 eXile

呵呵, 相信只要随便翻一翻XP的书, 都会说到这些问题. 不过我还是说一说,

1)极限编程却放弃这种追求 ....
XP追求的正是模块化和开放性

2)结果就是产生一大堆丑陋的代码...
对于个人来说, 如果使用XP后写出的代码很丑陋, 那么可以肯定, 不使用XP写出的代码也不会好到那儿去; 对于开发小组来说,三个月XP实践还存在这种看法, 项目管理只能说是太失败了

3)为什么不在设计初期进行预防呢?
要是在设计初期就能想到所有的变化和细节, 也就不会有XP了

4)关于代码与文档, 测试还是调试, 网上这种文章已经太多了

5)没有必要构造框架之类可复用的东西,无疑是与面向对象思想背道而驰的...
这只能说明你太不了解XP了,

  回复  更多评论   

# re: 反驳极限编程的四点理由 2007-07-08 23:58 eXile

不过从你所说的来看, 主要问题是, 没有了解XP的核心概念, 却盲目套用XP的外在形式,  回复  更多评论   

# re: 反驳极限编程的四点理由[未登录] 2007-07-09 09:38 shilei230

你说的都是点到为止,没有具体地阐述下去,似乎没有什么说服力.不过极限编程作为一种软件开发思想,确实有它的优势,我只是找到反驳它的四点理由,很乐意接受别人的反驳.我想看书要带着怀疑的态度去看,要通过自己的思考和实践看它好不好,挑它的毛病才能把它用好.阁下的反驳理由除了第三条,其它都是一笔带过,但是第三条我有说预防"所有的"变化和细节吗?呵呵,冒犯之处,多多原谅,希望能够共同提高,谢谢  回复  更多评论   

# re: 反驳极限编程的四点理由 2007-07-09 11:50 eXile

呵呵,共同学习,共同提高。
比如说第一点:追求模块化和开放性

模块的高内聚,低耦合是保证这一点的基础,怎么样做到这一点呢?由此产生各种面向对象的设计理论,而设计模式正是在设计方法在实践中产生的高度总结。但是做到这一点是不容易的,需要经过一定的锻炼和积累,应用哪一种设计模式
也不是一开始就能清晰的看出来的。而使用TDD,则强迫你做到这一点。一个模块性不好的单元,是很难进行测试的。程序员最容易犯的毛病,是把焦点过多的集中在实现的细节上,使用TDD,你首先必须把焦点放在功能的接囗上,而良好的接口,正是良好的设计的基础。
  回复  更多评论   

# re: 反驳极限编程的四点理由 2007-07-09 18:41 空明流转

小伙子不错,还知道有极限编程这么回事。  回复  更多评论   

# re: 反驳极限编程的四点理由[未登录] 2007-07-10 09:42 shilei230

极限编程的测试驱动所说的测试指的是单元测试,在前面的迭代计划阶段,可以认为它是在做需求分析和概要设计的事情。你说的理论是对的,但是实践的时候会很痛苦,因为很可能走弯路,你将不停地否认或修正自己最初的不成熟的设计,你也说了“强迫”,对吗?
对于有经验的程序员,他在分析需求的时候就大致知道要用什么设计模式,这些都是经过实践检验过的架构,绝对有助于写测试,也是软件复用的一个表现。如果不运用这些先验知识加以引导,每次都要摸着石头过河,目标能否实现是一个问题,即使实现了也可能要走不少弯路。不过如果迭代计划所做的卡足够小的话这个问题将不会太明显。
还有就是测试驱动更像是面向机器编程(先给出目标,然后根据机器的特性来实现),不像是面向对象编程(按照问题域来构造机器的实现)。
再有设计模式之类的架构,并不是实现细节,它搭的是一个框架。
欢迎反驳,呵呵  回复  更多评论   

# re: 反驳极限编程的四点理由 2007-07-10 16:20 eXile

极限编程的出现正是在现有开发模式下出现一系列问题后的一些探索。不过,适合自己的才是最好的,如果你觉得现有的的知识和经验可以为你解决这些问题,就没有必要为敏捷而敏捷  回复  更多评论   

# re: 反驳极限编程的四点理由 2008-07-28 12:28 jiero

我认为你应该好好的去看看设计模式这本书,你对极限编程恐怕也只是肤浅的理解,何谈反驳?  回复  更多评论   

# re: 反驳极限编程的四点理由 2008-07-28 15:22 LOGOS

看到了不得的东西
留名关注  回复  更多评论   


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(2)

随笔档案

文章档案

搜索

最新评论

阅读排行榜

评论排行榜