極限編程在工控軟件開發中的應用

摘 要：極限編程是一種新近提出的輕量級軟件工程方法，它的高效和實用很快就吸引了大批軟件人員的關注。本文對極限編程的概念和模式進行了概要介紹，同時結合國內工控軟件開發的特點，試圖將極限編程的概念引入到國內的工控軟件領域。

關鍵詞：極限編程、實踐、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