一,极限编程
极限编程(ExtremeProgramming(XP)是一套完整的涉及软件开发各个方面的开发观念,这里截取编码相关部分。
1.组队编程(PairProgramming)
XP中,所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过,代码、设计和测试的质量因此得到提高。看起来这样象是在浪费人力资源,但是各种研究表明事实恰恰相反。——这种工作方式极大地提高了工作强度和工作效率。
在实际工作中,你的老板可能不会同意你这么干,我们可以考虑一个变通的实现方法。在项目中,总会存在大量类似的工作,将这个工作安排给至少两个人以上共同承担,这些人为一组,在复核的时候互换角色。同样可以在一定程度上达到目的。这样做复核人员对自己所要复核的内容比较熟悉,可以保证工作质量与效率,同时每一项任务至少有两个人以上对其熟悉,这样在出现人员生病,离职等等调整的时候,项目经理不会因为某一位团队成员的变动,而对整个项目造成难以平衡的影响。
项目开发中,每个人会不断地更换合作编程的伙伴。因此,PairProgramming不但提高了软件质量,还增强了相互之间的知识交流和更新,增强了相互之间的沟通和理解。这不但有利于个人,也有利于整个项目、开发队伍和公司。项目经理在做好项目的同时,已有责任与义务,为公司培养优秀的人才。而更多优秀的人才,会使你的工作变得轻松。
2.测试驱动开发
反馈是XP的四个基本的价值观之一——在软件开发中,只有通过充分的测试才能获得充分的反馈。XP中提出的测试,在其它软件开发方法中都可以见到,比如功能测试、单元测试、系统测试和负荷测试等;与众不同的是,XP将测试结合到它独特的螺旋式增量型开发过程中,测试随着项目的进展而不断积累。另外,由于强调整个开发小组拥有代码,测试也是由大家共同维护的。即,任何人在往代码库中放程序(CheckIn)前,都应该运行一遍所有的测试;任何人如果发现了一个BUG,都应该立即为这个BUG增加一个测试,而不是等待写那个程序的人来完成;任何人接手其他人的任务,或者修改其他人的代码和设计,改动完以后如果能通过所有测试,就证明他的工作没有破坏愿系统。这样,测试才能真正起到帮助获得反馈的作用;而且,通过不断地优先编写和累积,测试应该可以基本覆盖全部的客户和开发需求,因此开发人员和客户可以得到尽可能充足的反馈。
3.重整和优化(Refactoring)
XP强调简单的设计,但简单的设计并不是没有设计的流水账式的程序,也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个USERSTORY都进行简单设计,但同时也在不断地对设计进行改进,这个过程叫设计的重整和优化(Refactoring)。这个名字最早出现在MartinFowler写的《Refactoring:ImprovingtheDesignofExistingCode》这本书中。
Refactoring主要是努力减少程序和设计中重复出现的部分,增强程序和设计的可重用性。Refactoring的概念并不是XP首创的,它已经被提出了近30年了,而且一直被认为是高质量的代码的特点之一。但XP强调,把Refactoring做到极致,应该随时随地、尽可能地进行Refactoring,只要有可能,程序员都不应该心疼以前写的程序,而要毫不留情地改进程序。当然,每次改动后,程序员都应该运行测试程序,保证新系统仍然符合预定的要求。
1. 频繁地整合,集体拥有代码(CollectiveCodeOwnership),编程规范
XP开发小组经常整合不同的模块。为了提高软件质量,除了测试驱动开发和PairProgramming以外,XP要求每个人的代码都要遵守编程规范,任何人都可以修改其他人写的代码,而且所有人都应该主动检查其他人写的代码。
频繁地整合(Integration)
在很多项目中,开发人员往往很迟才把各个模块整合在一起。在这些项目中,开发人员经常在整合过程中发现很多问题,但不能肯定到底是谁的程序出了问题;而且,只有整合完成后,开发人员才开始稍稍使用整个系统,然后就马上交付给客户验收。对于客户来说,即使这些系统能够通过终验收测试,因为使用时间短,客户们心里并没有多少把握。
为了解决这些问题,XP提出,整个项目过程中,应该频繁地,尽可能地整合已经开发完的USERSTORY(每次整合一个新的USERSTORY)。每次整合,都要运行相应的单元测试和验收测试,保证符合客户和开发的要求。整合后,就发布一个新的应用系统。这样,整个项目开发过程中,几乎每隔一两天,都会发布一个新系统,有时甚至会一天发布好几个版本。通过这个过程,客户能非常清楚地掌握已经完成的功能和开发进度,并基于这些情况和开发人员进行有效地、及时地交流,以确保项目顺利完成。
集体拥有代码(CollectiveCodeOwnership)
在很多项目开发过程中,开发人员只维护自己的代码,而且很多人不喜欢其他人随意修改自己的代码。因此,即使可能有相应的比较详细的开发文档,但一个程序员却很少、也不太愿意去读其他程序员的代码;而且,因为不清楚其他人的程序到底实现了什么功能,一个程序员一般也不敢随便改动其他人的代码。同时,因为是自己维护自己的代码,可能因为时间紧张或技术水平的局限性,某些问题一直不能被发现或得到比较好的解决。针对这点,XP提倡大家共同拥有代码,每个人都有权利和义务阅读其他代码,发现和纠正错误,重整和优化代码。这样,这些代码就不仅仅是一两个人写的,而是由整个项目开发队伍共同完成的,错误会减少很多,重用性会尽可能地得到提高,代码质量是非常好。
为了防止修改其他人的代码而引起系统崩溃,每个人在修改后都应该运行测试程序。(从这点,我们可以再次看到,XP的各个惯例和规则是怎样有机地结合在一起的。)
编程规范
XP开发小组中的所有人都遵循一个统一的编程标准,因此,所有的代码看起来好像是一个人写的。因为有了统一的编程规范,每个程序员更加容易读懂其他人写的代码,这是是实现CollectiveCodeOwnership的重要前提之一。