敏捷过程在中国软件企业的实践——XP最佳实践第三部分

 

接上一篇。。。。。。

 

段誉：“接下来要讲的实践是XP实践之中最受争议的一个，但也是XP实践中非常重要的一个，因为它是XP简单价值观的重要支撑点，同时它也影响到了XP的另外两个重要的实践简单设计和代码集体所有权，它是什么呢？它就是结对编程。关于结对编程的争议可以说是众说纷纭，往往也是XP方法学中争论得最为激烈的一个，我们可以找到很多对它有着深入评论的书籍和论文，在这里我们无法简单的用好或者不好来给它下一个定论，但它确实是XP思想体系之中重要的一个实践。XP的结对编程指的是在程序开发中由两个开发人员肩并肩的坐在一台电脑前，一个开发人员负责编码实现，一个开发人员考虑接口的设计、代码的审查和重构、错误的发现、性能的提高，我们可以比喻为在水上行驶的帆船上的两个人，一个负责划桨，一个负责控制方向。此外，这种结对的程序员之间是经常轮换的，这样能保证团队内部知识的传递。”

 

乔峰：“XP的这种实践看起来对大部分公司是很难接受的，主要基于两个原因，第一，我们会置疑两个人做到同一台电脑前编写同一段代码这会不会大大降低了开发效率？第二，大多数开发人员是不愿意与其它人一起共同编码的。我倒觉得我们的团队在开发过程中应该鼓励大家在遇到问题的时候，开发人员应该互相请教，坐下来共同解决棘手的难题，但不应该要求开发人员去进行结对编程。”

 

段誉：“我也赞同你的说法，但由于结对编程对XP有着重要的影响，简单的去掉它肯定是不行，我们还要考虑其造成的不良效果，接下来我先介绍XP的另外两个实践，再反过来考虑结对编程，这两个实践就是简单设计和代码集体所有权。在敏捷方法学的领域里，文档一向都被认为是不敏捷的标志，因此无论是哪一个敏捷过程，都是不强调拥有过多的文档的，XP就更是如此，XP相比其它敏捷方法学对文档的需求程度是更少的，由于它拥有着现场的客户，因此它只需要少量的需求文档，由于它强调简单的价值观，在《解析极限编程——拥抱变化》第一版中Kent Beck提出了简单设计的实践。与复杂设计相比，简单设计的编码更快、更敏捷，维护更简单，XP一个驱动设计的原则就是‘总是用最简单的方法做想做的事情’，也就是说不要设计和编写与当前迭代周期无关的代码。Kent Beck的这种说法也同时关联到了另外两个延伸的概念，那就是增量设计和紧急设计，我把它们一起合并到简单设计的实践中来。增量设计是Kent Beck在该书第二版中指出来的，它的意思是说在每次迭代中，我们都应该让设计的量恰好与当前迭代需要的水平相当；紧急设计是Ron Jeffries在《Extreme Programming Installed》一书中提到的：‘把一些人召集在一起，花几分钟制定出设计草案，十分钟就很理想，顶多半个小时，然后，最该做的就是直接编码了。’”

 

虚竹：“我对Kent Beck所说的简单设计和增量设计的概念还是深表赞同的，我们在开发中为了保持项目的敏捷，从设计上、编码上确实首先应该考虑最简单的方案，只要最简单的方案能够满足我们当前的要求就足够了，很多时候未来的需求是不确定的，考虑过多未来仍然还没有确定的需求，采用复杂的方案往往会得不偿失。同样我们既然已经选定了迭代式的开发，增量设计是必然的，每次迭代的设计量当然应该以恰好满足该次迭代的编码需求作为界限，过多的设计也是没有必要的，它会减缓项目的敏捷性。此外，关于Ron Jeffries提出的紧急设计的观点你们有什么看法？”

 

段誉：“XP认为每次迭代的前期进行详细的预先设计是不敏捷的，它拥有另外四个实践来避免由于缺少预先设计带来的不良影响从而增加项目的敏捷性，它们分别是紧急设计、结对编程、测试驱动设计、重构。由于有了紧急设计，在编码开始之前我们可以花费一段不长的时间进行设计的考虑；由于有了结对编程，可以一个人编写代码，另一个人考虑设计的问题，因此可以促使我们在编写代码的过程中逐步进行设计；由于有了测试驱动设计，我们可以在编码之前先编写测试，考虑接口和方法的设计；由于有了重构，我们可以在代码编写完成以后进行大量的代码重构，改进设计。正因为XP有着这么多实践的支撑，它才能够认为迭代前的详细设计是不必要的。”

 

乔峰：“嗯，是这样，但我们要想想，不要说我们公司缺少了结对编程，就算不缺少，XP的这种不做预先详细设计的方式在我们公司也是很难行得通的。”

 

段誉：“哦，愿闻其详。”

 

乔峰：“首先所谓的紧急设计只是一个开发之前的粗略设计，匆忙之下就进入编码阶段，必定会造成很多细节被忽略。当然这时候可以通过测试驱动设计和重构来弥补，但测试驱动设计只是针对接口和方法的设计，事实上它还是站在一个较为微观的角度来考虑问题，而迭代前的预先设计是站在宏观的角度，以微观的角度来代替宏观角度的设计这本来就不合理。而重构呢？我们固然可以在事后发现设计有问题的时候进行代码的重构，我举个例子，假设在院线系统最为复杂的模块之一票价策略，如果不事先进行详细的设计，由于业务逻辑的复杂性那么后期必然会导致代码的大量反复重构，这时候的开发效率反而远远不如在事先就进行了详细的设计，把主要的问题想清楚来得好，即使事先有些问题无法想清楚，那时再在后期进行重构也为时不晚。在敏捷过程的创始人、软件设计大师ROBERT C. MARTIN所写的经典之作《敏捷软件开发——原则、模式与实践》中，他也赞同在开发之前要建立一套设计模型，当然他同时也强调系统设计必须采用迭代的方式，在每一次迭代之前进行系统建模，然后在测试驱动设计与编码阶段不断去完善设计模型。”

 

段誉：“那么结对编程呢？如果有了结对编程是不是会弥补一二？”

 

虚竹：“这个问题我来回答吧，结对编程在某些公司确实能够弥补这个缺点，但我们公司不行，为什么呢？首先我们已经谈到，在我们公司要引入结对编程的实践是不太可能的；其次，就算我们采用了结对编程，要真正代替事先的详细设计也是有个前提的，那就是结对程序员彼此的水平要都比较高，能够在结对的过程中经过讨论并得到较为合理的设计，但我们的团队未必就能达到这种水平。”

 

乔峰：“另外，我还有一个疑问，在XP中没有详细的需求文档和设计文档，那么系统完成以后的维护怎么办呢？”

 

段誉：“在维护阶段既然我们已经开发完成了系统，那么运行中的系统、用户故事、验收测试清单和客户就是最好的需求文档。至于设计文档的缺失XP通过三个途径来弥补，第一，由于XP是采用测试驱动开发，它会产生大量的测试代码，XP认为这是最好的设计文档；第二，XP会进行大量的代码重构，并且坚持统一的编码标准，这会产生结构清晰、简单易懂的代码，便于日后的维护；第三，XP采用结对编程，在开发过程中团队内部每一对程序员都会经常轮换，这导致了团队每一个程序员都熟悉整套系统的代码，为日后的维护带来便利。”

 

乔峰：“对此我持有保留意见，首先，测试代码和结构清晰、简单易懂的程序代码可以作为设计文档之一这点我是赞同的，但它并不能完全代替采用UML之类的形式表示的系统模型文档，在维护阶段的维护人员不一定是开发系统的程序员，如果拥有模型文档能够让维护人员在一开始就对整个系统的全局有一个较好的把握，高屋建瓴，然后再具体深入到一些代码细节，这才是最符合人类逻辑思维的方式，而XP仅仅强调代码的细节，我觉得有失偏颇；其次，通过结对编程的轮换使得每个开发人员都熟悉系统代码，为维护带来便利，也避免由于团队成员的流失而对项目团队带来过大的影响，从设想来说是非常好的，但有两个问题是难以避免的，第一，如果系统的规模过大，通过轮换也不能让每个程序员熟悉所有的代码，轮换的作用就会大大减弱，第二，后期系统的维护人员可能完全不同于原来系统的开发人员，这样轮换的作用也会大为降低。”

 

段誉：“看来XP的紧急设计、不进行详细设计的这个理念在具体执行的过程中会遇到很多的挑战，我觉得我们还是应该保留我们原来各项目团队所采用的详细设计思想了。”

 

虚竹：“对于详细设计我也有不同的看法，对于敏捷过程来说，过多的文档本身就意味着是不敏捷的，这是有一定道理的，我们固然承认对我们公司来说在每一次迭代之前只做紧急设计不符合我们的现状，但并不意味着纯粹的详细设计就是符合我们公司现状的。”

 

段誉：“这是何意？”

 

虚竹：“在软件开发方法学的领军人物Scott W. Ambler所著的一本书《敏捷建模：极限编程和统一过程的有效实践》里面，作者提到了敏捷模型驱动开发的方法，作者认为设计并不是越详细越好，为了保持项目的敏捷性，我们必须采用通用的建模标准，采用增量建模，在建模的时候我们必须保持模型的实际内容在满足项目要求的情况下尽可能的简单，我们可以创建很多临时的模型，一旦完成目的就可以丢弃等等。现在来考察一下我们项目团队中发生的实际情况，你们有没有发现，在我们很多项目中，往往我们的设计模型出了不少问题，设计的目的为了什么？主要有两个目的，第一个最主要的目的是为了能在接下来的编码阶段让程序员根据设计的文档编写代码，实现设计思想的传递，第二个目的是为了今后系统的维护。因此我们设计最重要的标准就是明确无误的传递设计思想，你们认为呢？”

 

段誉：“是这样。”

 

虚竹：“说到这里问题就出来了，首先，在系统很多足够简单不需要详细设计只需要紧急设计的地方进行了无谓的设计，降低了项目的敏捷性；其次，在系统业务逻辑比较复杂的地方设计得不够，没有利用各种模型从多个不同的视角描述系统，造成了设计与编码的脱节，设计思想得不到明确的传达。”

 

未完待续。。。