摘 要：極限編程是一種新近提出的輕量級軟件工程方法，它的高效和實用很快就吸引了大批軟件人員的關(guān)注。本文對極限編程的概念和模式進行了概要介紹，同時結(jié)合國內(nèi)工控軟件開發(fā)的特點，試圖將極限編程的概念引入到國內(nèi)的工控軟件領(lǐng)域。 關(guān)鍵詞：極限編程、實踐、UML、結(jié)對編程 一、極限編程 　　極限編程（eXtreme Programming，簡稱XP）是Kent Beck在二十世紀九十年代提出的一種輕量級軟件工程方法。這種方法與傳統(tǒng)軟件工程方法幾乎背道而馳，其提出在業(yè)界產(chǎn)生了巨大的震動，甚至有人根本不相信其可行性。大量的實踐證明，極限編程是一種高效實用軟件工程方法。 　　軟件設(shè)計的方式可分為兩種：計劃式設(shè)計和演進式設(shè)計。計劃式設(shè)計出現(xiàn)于20世紀70年代，它要求設(shè)計者事先仔細考慮所有的重大問題，不要求他們編寫代碼。設(shè)計者們使用一種能夠拋開編程細節(jié)的設(shè)計技術(shù)（如UML）在一個抽象的層次上工作。設(shè)計完成后被移交給程序員們進行實際的構(gòu)建，因為是預(yù)先考慮了幾乎所有的問題，所以只要程序員遵從設(shè)計，就會構(gòu)建出良好的軟件。演進式設(shè)計其實是最原始最普通的設(shè)計方法——編碼加修正，這意味著系統(tǒng)設(shè)計伴隨著系統(tǒng)實現(xiàn)而成長，設(shè)計是編程過程的一部分，而且隨著程序的演變，設(shè)計也在變化。普通的演進設(shè)計是存在著致命缺陷的，由于設(shè)計的不斷變化，設(shè)計最終成為了一堆隨機應(yīng)變決策的拼湊。每種決策都使代碼更加難以改變，隨著時間的推移，軟件有效更改的能力不斷下降，而缺陷和漏洞卻越來越多且難以被發(fā)現(xiàn)，設(shè)計者最后將遇到軟件失序的狀態(tài)。此時隨著項目的進展，修正缺陷的代價會呈指數(shù)增長。 　　計劃設(shè)計使軟件設(shè)計成為了一種系統(tǒng)的工程方法，其在很多方面都要比演進設(shè)計更好，但計劃設(shè)計也存在著問題。首先，計劃設(shè)計在計劃時不可能將編程時需要處理的所有問題都考慮到，這種編程和設(shè)計上的沖突將最終引入失序。其次，很多時候設(shè)計者本身也是編程者，當設(shè)計者全身心投入設(shè)計時，在編程方面必然會落后于軟件開發(fā)工具和資料的飛速發(fā)展，這就意味著設(shè)計上考慮不周的可能性會變大。而一個編程者必須要非常嫻熟才可能對設(shè)計者的設(shè)計產(chǎn)生質(zhì)疑，這種緊張關(guān)系將帶來隱患。再次，需求變化是計劃設(shè)計中最令人頭疼的問題，需求變化分為可預(yù)見的和不可預(yù)見的，可預(yù)見變化可以通過在設(shè)計中引入柔性來合理改變計劃，但不可預(yù)見變化的解決卻非常困難。雖然存在上述缺陷，但計劃設(shè)計因其相對演進設(shè)計的優(yōu)越性而成為軟件開發(fā)的主流設(shè)計方法。 　　極限編程提倡演進設(shè)計而不是計劃設(shè)計，但是極限編程通過一套系統(tǒng)的實踐（Practice）彌補了演進設(shè)計的致命缺陷。它將軟件項目分為多個迭代周期，每個周期實現(xiàn)部分軟件功能。在每個周期都進行提出需求、架構(gòu)設(shè)計、編碼、測試和發(fā)布等幾個環(huán)節(jié)，每個周期都進行充分的測試和集成。這樣做可以不斷從客戶方面得到反饋，更逼近實際軟件需求。通過頻繁的重新編碼的過程，可以適應(yīng)需求的變化，也增加了易維護性。在不斷的迭代中，避免了架構(gòu)設(shè)計出現(xiàn)重大失誤所造成的風險。極限編程的實踐主要包括：計劃、小版本、隱喻、簡單設(shè)計、測試、重構(gòu)、結(jié)對編程、集體所有權(quán)、持續(xù)集成、現(xiàn)場客戶和編碼標準等。 　　● 計劃是指通過結(jié)合使用業(yè)務(wù)優(yōu)先級和技術(shù)評估來快速確定軟件下一個版本的范圍。當計劃趕不上實際變化的時候就應(yīng)更新計劃。 　　● 小版本是指將每個版本要實現(xiàn)的功能在符合需求的前提下盡可能的小，從而縮短每個版本的開發(fā)周期。 　　● 隱喻是指對整個系統(tǒng)如何運行所做的描述，用于幫助項目中的每個人理解項目的基本元素以及它們之間的關(guān)系。 　　● 簡單設(shè)計是指盡可能簡單的進行設(shè)計，去掉任何不必要的復(fù)雜性。 　　● 測試即指在開發(fā)的過程中，程序員必須不斷編寫單元測試，在這些測試都能正確運行后才可以繼續(xù)開發(fā)?？蛻粢惨帉憸y試來證明要求的功能已經(jīng)完成。 　　● 重構(gòu)是指程序員為了去除重復(fù)、改善溝通、提高程序的柔性，在不更改系統(tǒng)行為的前提下對其進行重新構(gòu)造。 　　● 結(jié)對編程是指所有的代碼都是由兩個人使用同一臺計算機編寫的。結(jié)對的兩個人中正在使用鍵盤和鼠標的人應(yīng)思考編寫當前代碼的最佳途徑，另一個人則應(yīng)偏重于在戰(zhàn)略性的角度進行思考。 　　● 集體所有權(quán)是指代碼為集體所有，團隊中的任何成員在任何時刻都可以在系統(tǒng)中的任何位置更改任何代碼。集體所有權(quán)的前提是XP團隊中的任何成員都要團結(jié)并有責任心。 　　● 持續(xù)集成是指經(jīng)常性的對代碼進行集成和測試。這樣做有利于檢查程序整體的可靠性以及在測試失敗時，迅速確診存在錯誤的代碼。 　　● 現(xiàn)場客戶是指XP團隊中必須存在一個客戶進行業(yè)務(wù)配合，他將全職負責回答問題、解決爭端和確定優(yōu)先級。 　　● 編碼標準是指代碼須按照整個團隊都同意采納的標準進行編寫，這樣才能確保結(jié)對程序員通過代碼進行溝通。 　　極限編程的上述任何一個實踐都不是獨特或首創(chuàng)的，某些單獨的實踐甚至還存在缺陷，但XP要求在開發(fā)過程中各個實踐要相互支持，從而使整個開發(fā)過程走向成功。 二、國內(nèi)工控軟件開發(fā)的特點 　　國內(nèi)工控行業(yè)正處于發(fā)展階段，工控軟件的開發(fā)大多都具有研發(fā)性質(zhì)。而國內(nèi)的軟件行業(yè)也處于發(fā)展階段，缺少成熟的軟件團隊，缺少高素質(zhì)的開發(fā)人員和管理人員。在這種背景下，使得國內(nèi)工控軟件的開發(fā)具有如下特點： 　　1、開發(fā)團隊規(guī)模小。國內(nèi)工控行業(yè)的軟件多數(shù)都是具有研發(fā)性質(zhì)的長周期中小型軟件，如盲目投入大量的人力，往往無謂提高成本。另外國內(nèi)軟件行業(yè)缺少具有大規(guī)模團隊管理經(jīng)驗的人才，團隊規(guī)模大了往往管理跟不上，反而使開發(fā)效率降低，產(chǎn)品質(zhì)量也很難保證，所以國內(nèi)工控軟件的團隊多是十人甚至更少的規(guī)模。 　　2、需求模糊導(dǎo)致前期工作不充分。國內(nèi)工控行業(yè)多數(shù)軟件項目是對國外已有技術(shù)的研制，往往功能需求模糊。開發(fā)團隊在進行需求分析和概要設(shè)計時，很難做出充分準備并制定出完善的體系結(jié)構(gòu)。這類項目在開發(fā)中后期還經(jīng)常發(fā)生需求的變化。 　　3、團隊的角色不完整。國內(nèi)工控軟件開發(fā)團隊往往缺乏稱職的項目經(jīng)理，也很少在項目中專門安插一個領(lǐng)域?qū)＜遥瑴y試員往往由程序員兼任，客戶即使存在也很難做到良好的溝通和反饋。角色的缺乏和混淆使得管理難上加難，大大降低了工作效率。 　　4、程序員觀念陳舊，缺乏團隊合作精神。到現(xiàn)在為止，國內(nèi)很多程序員仍然信奉著“個人英雄”主義。他們工作上個人能力很強，但是長期的獨立工作，往往導(dǎo)致與他人的溝通與交流出現(xiàn)問題。這些顯然已經(jīng)不符合現(xiàn)代軟件開發(fā)的需求了。 　　5、“格子”式工作環(huán)境——把一間大辦公室用隔斷分隔成多個小格子，每個人都在自己的格子里工作。這種工作環(huán)境很不適合進行研究開發(fā)：較高的隔斷使得人們交流變得困難，狹窄的格子很難同時坐進2到3個人，也很難放下較大的開發(fā)設(shè)備。 三、極限編程在工控軟件開發(fā)中的應(yīng)用 　　經(jīng)過國外近幾年的實踐證明，XP的確是一種優(yōu)秀的開發(fā)方法，但是因為實際情況的不同，在國內(nèi)工控軟件的開發(fā)上全套照搬極限編程的模式是不現(xiàn)實的，這里面即存在著傳統(tǒng)觀念的阻力，也有著人員素質(zhì)的問題。要改變?nèi)藗冮L期以來習慣了的工作方式，必須循序漸進的逐步更改。針對國內(nèi)工控軟件開發(fā)的上述特點，可以考慮先在項目過程中引入XP的幾個較容易見到效果并被開發(fā)人員接受的實踐，待團隊中的成員在進行這些實踐中自己逐漸意識到問題所在后，再將XP的內(nèi)容進一步引入，并根據(jù)實際情況進行適當調(diào)整。 　　第一是計劃實踐，通常情況下，開發(fā)團隊的管理人員傾向于根據(jù)客戶的需要制定時間表，卻不去切實了解實現(xiàn)需求的過程細節(jié)，此時所制定的時間表往往是不切實際的。而客戶的需求很少去考慮實際開發(fā)過程或者功能范圍的調(diào)整，只是期望在預(yù)期的時間拿到預(yù)期的成果。這樣所制定的計劃一旦實行，伴隨而來的會是大量的中期協(xié)商和觀點折衷，而最終產(chǎn)品很難按期交付。XP的計劃實踐要求客戶和開發(fā)團隊的所有人員參與計劃的制定，首先要由客戶和開發(fā)人員一起確定項目要完成的所有任務(wù)及其優(yōu)先級，然后由開發(fā)人員對這些任務(wù)進行估計并制定時間表和給每個開發(fā)人員分配工作。在項目開發(fā)過程中對時間表的任何調(diào)整都要在問題出現(xiàn)的時候立即完成。 　　第二是結(jié)對編程，習慣上是反對兩個人一起開發(fā)代碼的。管理人員認為開發(fā)代碼所需人數(shù)加倍是浪費資源，程序員認為編程在傳統(tǒng)上是作為一種孤立活動進行的。但定量的證據(jù)表明結(jié)對編程使設(shè)計的結(jié)果更好，生成的代碼更簡單，更易于擴展，老練的結(jié)對程序員認為結(jié)對工作的速度要比單獨工作的速度快2倍以上。 　　第三是測試自動化，一個全面的測試程序是一個項目成功的關(guān)鍵。一個項目的測試在剛剛開始的時候不可能有全面的測試，但必須先制定一個柔性測試框架。在每個單元的開發(fā)過程中產(chǎn)生相應(yīng)的樣本數(shù)據(jù)、單元測試和功能測試，然后集成到測試框架中，最后達到一個完整的測試覆蓋率。 　　第四是集成和發(fā)布，團隊可考慮設(shè)置一臺專門的集成工作站，所有當前代碼庫和測試程序都集中在該工作站上，每個開發(fā)人員都將自己的代碼與集成工作站的代碼庫進行集成，并運行所有的測試程序。在測試程序覆蓋率不足的時候，可將未測試部分羅列成表，每個人根據(jù)該表補充不足部分，并定期檢查更新該表。 　　第五是工作環(huán)境，XP的溝通是非常重要的。一個良好的工作環(huán)境可以改善人與人之間的溝通氛圍，提高人們交流的積極性。一個標準的XP團隊工作環(huán)境應(yīng)該是一個大的通透空間，中間（公共區(qū)域）集中了所有的工作設(shè)備，每臺計算機前至少有夠坐下兩個人的空間，椅子是一定要方便移動的。四壁要有大面積的白板，人們需要討論時可隨時隨地進行。四周可以安排些小房間用作休息和處理私人事務(wù)。項目負責人可以有自己的辦公室，但在進行開發(fā)時一定要進入公共區(qū)域——這里沒有等級。 　　以上提到的都是基礎(chǔ)性的實踐，隨著這些實踐為團隊所接受，每個成員會逐漸意識到XP的真髓。這個時候再一一引入其它實踐并檢驗這些實踐的效果，適當予以揚棄，從而最終形成自己的軟件工程方法和一個成熟的團隊。 四、結(jié)束語 　　XP是一個極具潛力的軟件工程方法，雖然XP的很多方法和道理都是早為人知的，但少有人去想把它們系統(tǒng)的結(jié)合起來，Kent Beck在這方面做了大膽的嘗試，并取得了驚人的成功。當然，工控行業(yè)的軟件開發(fā)有著自己的特點，XP的模式一定不會完全適合，但是XP所提倡的理念是非常值得我們深思和借鑒的。 參考文獻 　　[1] Kent Beck，《解析極限編程——擁抱變化》，人民郵電出版社，2002 　　[2] Kent Beck，《規(guī)劃極限編程》，人民郵電出版社，2002 　　[3] Kent Beck，《極限編程實施》，人民郵電出版社，2002 　　[4] Kent Beck，《極限編程實踐》，人民郵電出版社，2002 　　[5] 網(wǎng)站：Extreme Programming Online，http://www.extremeprogramming.org 　　[6] Brooks，《人月神話》，清華大學(xué)出版社，2002