极限编程在工控软件开发中的应用

摘  要：极限编程是一种新近提出的轻量级软件工程方法，它的高效和实用很快就吸引了大批软件人员的关注。本文对极限编程的概念和模式进行了概要介绍，同时结合国内工控软件开发的特点，试图将极限编程的概念引入到国内的工控软件领域。
关键词：极限编程、实践、UML、结对编程
一、极限编程
　　极限编程（eXtreme Programming，简称XP）是Kent Beck在二十世纪九十年代提出的一种轻量级软件工程方法。这种方法与传统软件工程方法几乎背道而驰，其提出在业界产生了巨大的震动，甚至有人根本不相信其可行性。大量的实践证明，极限编程是一种高效实用软件工程方法。
　　软件设计的方式可分为两种：计划式设计和演进式设计。计划式设计出现于20世纪70年代，它要求设计者事先仔细考虑所有的重大问题，不要求他们编写代码。设计者们使用一种能够抛开编程细节的设计技术（如UML）在一个抽象的层次上工作。设计完成后被移交给程序员们进行实际的构建，因为是预先考虑了几乎所有的问题，所以只要程序员遵从设计，就会构建出良好的软件。演进式设计其实是最原始最普通的设计方法——编码加修正，这意味着系统设计伴随着系统实现而成长，设计是编程过程的一部分，而且随着程序的演变，设计也在变化。普通的演进设计是存在着致命缺陷的，由于设计的不断变化，设计最终成为了一堆随机应变决策的拼凑。每种决策都使代码更加难以改变，随着时间的推移，软件有效更改的能力不断下降，而缺陷和漏洞却越来越多且难以被发现，设计者最后将遇到软件失序的状态。此时随着项目的进展，修正缺陷的代价会呈指数增长。
　　计划设计使软件设计成为了一种系统的工程方法，其在很多方面都要比演进设计更好，但计划设计也存在着问题。首先，计划设计在计划时不可能将编程时需要处理的所有问题都考虑到，这种编程和设计上的冲突将最终引入失序。其次，很多时候设计者本身也是编程者，当设计者全身心投入设计时，在编程方面必然会落后于软件开发工具和资料的飞速发展，这就意味着设计上考虑不周的可能性会变大。而一个编程者必须要非常娴熟才可能对设计者的设计产生质疑，这种紧张关系将带来隐患。再次，需求变化是计划设计中最令人头疼的问题，需求变化分为可预见的和不可预见的，可预见变化可以通过在设计中引入柔性来合理改变计划，但不可预见变化的解决却非常困难。虽然存在上述缺陷，但计划设计因其相对演进设计的优越性而成为软件开发的主流设计方法。
　　极限编程提倡演进设计而不是计划设计，但是极限编程通过一套系统的实践（Practice）弥补了演进设计的致命缺陷。它将软件项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、架构设计、编码、测试和发布等几个环节，每个周期都进行充分的测试和集成。这样做可以不断从客户方面得到反馈，更逼近实际软件需求。通过频繁的重新编码的过程，可以适应需求的变化，也增加了易维护性。在不断的迭代中，避免了架构设计出现重大失误所造成的风险。极限编程的实践主要包括：计划、小版本、隐喻、简单设计、测试、重构、结对编程、集体所有权、持续集成、现场客户和编码标准等。
　　● 计划是指通过结合使用业务优先级和技术评估来快速确定软件下一个版本的范围。当计划赶不上实际变化的时候就应更新计划。
　　● 小版本是指将每个版本要实现的功能在符合需求的前提下尽可能的小，从而缩短每个版本的开发周期。
　　● 隐喻是指对整个系统如何运行所做的描述，用于帮助项目中的每个人理解项目的基本元素以及它们之间的关系。
　　● 简单设计是指尽可能简单的进行设计，去掉任何不必要的复杂性。
　　● 测试即指在开发的过程中，程序员必须不断编写单元测试，在这些测试都能正确运行后才可以继续开发。客户也要编写测试来证明要求的功能已经完成。
　　● 重构是指程序员为了去除重复、改善沟通、提高程序的柔性，在不更改系统行为的前提下对其进行重新构造。
　　● 结对编程是指所有的代码都是由两个人使用同一台计算机编写的。结对的两个人中正在使用键盘和鼠标的人应思考编写当前代码的最佳途径，另一个人则应偏重于在战略性的角度进行思考。
　　● 集体所有权是指代码为集体所有，团队中的任何成员在任何时刻都可以在系统中的任何位置更改任何代码。集体所有权的前提是XP团队中的任何成员都要团结并有责任心。
　　● 持续集成是指经常性的对代码进行集成和测试。这样做有利于检查程序整体的可靠性以及在测试失败时，迅速确诊存在错误的代码。
　　● 现场客户是指XP团队中必须存在一个客户进行业务配合，他将全职负责回答问题、解决争端和确定优先级。
　　● 编码标准是指代码须按照整个团队都同意采纳的标准进行编写，这样才能确保结对程序员通过代码进行沟通。
　　极限编程的上述任何一个实践都不是独特或首创的，某些单独的实践甚至还存在缺陷，但XP要求在开发过程中各个实践要相互支持，从而使整个开发过程走向成功。
二、国内工控软件开发的特点
　　国内工控行业正处于发展阶段，工控软件的开发大多都具有研发性质。而国内的软件行业也处于发展阶段，缺少成熟的软件团队，缺少高素质的开发人员和管理人员。在这种背景下，使得国内工控软件的开发具有如下特点：
　　1、开发团队规模小。国内工控行业的软件多数都是具有研发性质的长周期中小型软件，如盲目投入大量的人力，往往无谓提高成本。另外国内软件行业缺少具有大规模团队管理经验的人才，团队规模大了往往管理跟不上，反而使开发效率降低，产品质量也很难保证，所以国内工控软件的团队多是十人甚至更少的规模。
　　2、需求模糊导致前期工作不充分。国内工控行业多数软件项目是对国外已有技术的研制，往往功能需求模糊。开发团队在进行需求分析和概要设计时，很难做出充分准备并制定出完善的体系结构。这类项目在开发中后期还经常发生需求的变化。
　　3、团队的角色不完整。国内工控软件开发团队往往缺乏称职的项目经理，也很少在项目中专门安插一个领域专家，测试员往往由程序员兼任，客户即使存在也很难做到良好的沟通和反馈。角色的缺乏和混淆使得管理难上加难，大大降低了工作效率。
　　4、程序员观念陈旧，缺乏团队合作精神。到现在为止，国内很多程序员仍然信奉着“个人英雄”主义。他们工作上个人能力很强，但是长期的独立工作，往往导致与他人的沟通与交流出现问题。这些显然已经不符合现代软件开发的需求了。
　　5、“格子”式工作环境——把一间大办公室用隔断分隔成多个小格子，每个人都在自己的格子里工作。这种工作环境很不适合进行研究开发：较高的隔断使得人们交流变得困难，狭窄的格子很难同时坐进2到3个人，也很难放下较大的开发设备。
三、极限编程在工控软件开发中的应用
　　经过国外近几年的实践证明，XP的确是一种优秀的开发方法，但是因为实际情况的不同，在国内工控软件的开发上全套照搬极限编程的模式是不现实的，这里面即存在着传统观念的阻力，也有着人员素质的问题。要改变人们长期以来习惯了的工作方式，必须循序渐进的逐步更改。针对国内工控软件开发的上述特点，可以考虑先在项目过程中引入XP的几个较容易见到效果并被开发人员接受的实践，待团队中的成员在进行这些实践中自己逐渐意识到问题所在后，再将XP的内容进一步引入，并根据实际情况进行适当调整。
　　第一是计划实践，通常情况下，开发团队的管理人员倾向于根据客户的需要制定时间表，却不去切实了解实现需求的过程细节，此时所制定的时间表往往是不切实际的。而客户的需求很少去考虑实际开发过程或者功能范围的调整，只是期望在预期的时间拿到预期的成果。这样所制定的计划一旦实行，伴随而来的会是大量的中期协商和观点折衷，而最终产品很难按期交付。XP的计划实践要求客户和开发团队的所有人员参与计划的制定，首先要由客户和开发人员一起确定项目要完成的所有任务及其优先级，然后由开发人员对这些任务进行估计并制定时间表和给每个开发人员分配工作。在项目开发过程中对时间表的任何调整都要在问题出现的时候立即完成。
　　第二是结对编程，习惯上是反对两个人一起开发代码的。管理人员认为开发代码所需人数加倍是浪费资源，程序员认为编程在传统上是作为一种孤立活动进行的。但定量的证据表明结对编程使设计的结果更好，生成的代码更简单，更易于扩展，老练的结对程序员认为结对工作的速度要比单独工作的速度快2倍以上。
　　第三是测试自动化，一个全面的测试程序是一个项目成功的关键。一个项目的测试在刚刚开始的时候不可能有全面的测试，但必须先制定一个柔性测试框架。在每个单元的开发过程中产生相应的样本数据、单元测试和功能测试，然后集成到测试框架中，最后达到一个完整的测试覆盖率。
　　第四是集成和发布，团队可考虑设置一台专门的集成工作站，所有当前代码库和测试程序都集中在该工作站上，每个开发人员都将自己的代码与集成工作站的代码库进行集成，并运行所有的测试程序。在测试程序覆盖率不足的时候，可将未测试部分罗列成表，每个人根据该表补充不足部分，并定期检查更新该表。
　　第五是工作环境，XP的沟通是非常重要的。一个良好的工作环境可以改善人与人之间的沟通氛围，提高人们交流的积极性。一个标准的XP团队工作环境应该是一个大的通透空间，中间（公共区域）集中了所有的工作设备，每台计算机前至少有够坐下两个人的空间，椅子是一定要方便移动的。四壁要有大面积的白板，人们需要讨论时可随时随地进行。四周可以安排些小房间用作休息和处理私人事务。项目负责人可以有自己的办公室，但在进行开发时一定要进入公共区域——这里没有等级。
　　以上提到的都是基础性的实践，随着这些实践为团队所接受，每个成员会逐渐意识到XP的真髓。这个时候再一一引入其它实践并检验这些实践的效果，适当予以扬弃，从而最终形成自己的软件工程方法和一个成熟的团队。
四、结束语
　　XP是一个极具潜力的软件工程方法，虽然XP的很多方法和道理都是早为人知的，但少有人去想把它们系统的结合起来，Kent Beck在这方面做了大胆的尝试，并取得了惊人的成功。当然，工控行业的软件开发有着自己的特点，XP的模式一定不会完全适合，但是XP所提倡的理念是非常值得我们深思和借鉴的。
参考文献
　　[1] Kent Beck，《解析极限编程——拥抱变化》，人民邮电出版社，2002
　　[2] Kent Beck，《规划极限编程》，人民邮电出版社，2002
　　[3] Kent Beck，《极限编程实施》，人民邮电出版社，2002
　　[4] Kent Beck，《极限编程实践》，人民邮电出版社，2002
　　[5] 网站：Extreme Programming Online，http://www.extremeprogramming.org
　　[6] Brooks，《人月神话》，清华大学出版社，2002