关于XP

从旧文档里翻出一些很早以前写的东西,关于XP(eXtreme Programming)的。那时候的很多想法现在看起来还是挺有见地的,不过还是透着稚嫩和青涩。但也有让自己汗颜的地方 – 我似乎没有那时那种自信了。

22:42 2004-12-4
xp,大多数人都知道是一种软件开发的方法.不同以往的软件工程的方法,个人觉得根适用于较小型的项目.因为xp的参与者不宜过多,否则信息沟通上的消耗会影响到开发的速度.而这是xp最引以为豪的.
优秀的coder可以凭借经验和技巧迅速地构建一个系统,从软件最开始到现在一直存在这样的问题–个人英雄主义的滥觞.但随着软件需求的越来越复杂,多变,软件开发更需要一种契约化的,更注重需求分析和挖掘的软件开发模式–于是xp诞生了.
简单地说来,xp主要是以下几点:
1.测试先行
2.需求挖掘
3.重构,持续整合
当然还有一点很重要,在任何时候都很重要–良好的设计.
可以说,xp更适合那些有大量编码经验的开发人员.如果刚刚学完数据结构就想去找xp的麻烦,无疑是浪费时间,因为很可能会陷入xp海洋里而迷失了方向,导致对编程基础的忽视.而这是学习任何知识的大忌.
xp,你需要一些自动化工具来帮你完成一些重复工作,如初始化,编译,测试,打包,部署…其中最终要的一个工具就是ant,当然你也可以选择其他的ide,但ant无疑是最强大的,它的能耐决不仅仅是”make”.另一个比较重要的就是junit,单元测试工具.还有很多这里就不涉及了.
说了这么多,xp到底是什么样子的呢?下面是笔者一个比较不具体的例子,仅供参考.
首先,你要对项目的需求有足够的领悟,然后设计程序架构.但接着下来不是开始编码,而是部署和测试框架的搭建,这些groundwork对以后的开发及其重要,虽然看起来似乎是浪费了时间,之后就是编码和测试的并行进行(测试被提前了,不再是最后才做的工作).个人觉得xp有60%的时间是在测试相关的工作上,剩40%的时间才是编码.
xp应该不是java的专利,但是java才有ant.c? can’t?

同eclipse一样,ant也是一个开放的框架(也是为什么我们也把ant叫做ide的原因)

个人感觉xp还是满”高端”的一种概念,并不适合我们经常遇到的情况,往往我们在工作中看到的开发模式简直无法让人想象和xp的关联  — xp这种”见效不明显”的开发方法很难被急功近利的leader们认可.在这些人看来xp的效率是很低的,工作开展到一半的时间时我们还没有开始编码 — 老天!!storm the front!!
太过大型的项目用xp可能是不适合的,可能对开发人员的要求更高.xp适合的项目规模,两个小组,每个组2到3人,还有一个英明神武的leader,负责划分任务,设计测试框架,指导开发所需工具.有了这样的一个团队,应该是一般的企业级应用都可以胜任.

我很认同mmm的作者的一个观点,软件开发并不需要很多的人,即使是很大型的项目,人越多用来沟通,运筹的时间就越多.在软件开发领域同样存在80/20法则,20%的程序员做了80%的工作.那我们还为什么需要那80%的人呢?笔者不想在这里讨论这80%的人应该怎么处理,这不仅仅是软件开发,或者人力资源的问题了.可以说xp同样是软件开发模式向天才开发人员回归的一种表现,软件工程学一度曾让很多人认为程序员其实是很低级的重复劳动,coder只是code(包括一些小小的无法上升到一定高度的创意)

Comments are closed.