實驗三 java敏捷開發與XP

標籤：

一、實驗內容

 

（一）敏捷開發與XP

 

      軟體開發流程的目的是為了提高軟體開發、運營、維護的效率，並提高軟體的品質、使用者滿意度、可靠性和軟體的可維護性。 光有各種流程的思想是不夠的，我們還要有一系列的工具來保證這些思想能夠在實踐中有效率地運作。一個常見的公式是：軟體工程=開發流程+工具。敏捷開發（Agile Development）是一種以人為核心、迭代、循序漸進的開發方法。“敏捷流程”是一系列價值觀和方法論的集合。

 

其中，極限編程(eXtreme Programming，XP)是 是一種全新而快捷的軟體開發方法。XP團隊使用現場客戶、特殊計劃方法和持續測試來提供快速的反饋和全面的交流：

 

• XP是以開發符合客戶需要的軟體為目標而產生的一種方法論
• XP是一種以實踐為基礎的軟體工程過程和思想
• XP認為代碼品質的重要程度超出人們一般所認為的程度
• XP特別適合於小型的有責任心的、自覺自勵的團隊開發需求不確定或者迅速變化的軟體

 

XP軟體開發是什麼樣的通過 XP準則來表達：

 

• 溝通 ：XP認為項目成員之間的溝通是項目成功的關鍵，並把溝通看作項目中間協調與合作的主要推動因素。
• 簡單 ：XP假定未來不能可靠地預測，在現在考慮它從經濟上是不明智的，所以不應該過多考慮未來的問題而是應該集中力量解決燃眉之急。
• 反饋 ：XP認為系統本身及其代碼是報告系統開發進度和狀態的可靠依據。系統開發狀態的反饋可以作為一種確定系統開發進度和決定系統下一步開發方向的手段。
• 勇氣：代表了XP認為人是軟體開發中最重要的一個方面的觀點。在一個軟體產品的開發中人的參與貫穿其整個生命週期，是人的勇氣來排除困境，讓團隊把局部的最優拋之腦後，達到更重大的目標。表明了XP對“人讓項目取得成功”的基本信任態度。

 

一項實踐在XP環境中成功使用的依據通過XP的法則呈現，包括：快速反饋、假設簡單性、遞增更改、提倡更改、優質工作。

 

XP軟體開發的基石是XP的活動，包括：編碼、測試、傾聽、設計。

 

 

（二）編碼通訊協定

 

編程標準包含：具有說明性的名字、清晰的運算式、直截了當的控制流程、可讀的代碼和注釋，以及在追求這些內容時一致地使用某些規則和慣用法的重要性。

 

程式沒有最基本的縮排，讓人讀起來很費勁，這個問題在Eclipse中比較容易解決，我們單擊Eclipse菜單中的source->Format 或用快速鍵Ctrl+Shift+F就可以按Eclipse規定的規範縮排。

代碼標準中很重要的一項是如何給包、類、變數、方法等標識符命名，能很好的命名可以讓自己的代碼立馬上升一個檔次。Java中的一般的命名規則有：

• 要體現各自的含義
• 包、類、變數用名詞
• 方法名用動賓
• 包名全部小寫，如：io，awt
• 類名第一個字母要大寫，如：HelloWorldApp
• 變數名第一個字母要小寫，如：userName

方法名第一個字母要小寫：setName　

（三）結對程式設計

結對程式設計是XP中的重要實踐。在結對程式設計模式下，一對程式員肩並肩、平等地、互補地進行開發工作。他們並排坐在一台電腦前，面對同一個顯示器，使用同一個鍵盤、同一個滑鼠一起工作。他們一起分析，一起設計，一起寫測試案例，一起編碼，一起做單元測試，一起做整合測試，一起寫文檔等。 結對程式設計中有兩個角色：

• 駕駛員（Driver）是修飾鍵盤輸入的人。
• 領航員（Navigator）起到領航、提醒的作用。

如何結對程式設計，為何要結對程式設計，重點是：

• 駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。
• 領航員：審閱駕駛員的文檔、駕駛員對編碼等開發流程的執行；考慮單元測試的覆蓋率；思考是否需要和如何重構；協助駕駛員解決具體的技術問題。
• 駕駛員和領航員不斷輪換角色，不要連續工作超過一小時，每工作一小時休息15分鐘。領航員要控制時間。
• 主動參與。任何一個任務都首先是兩個人的責任，也是所有人的責任。沒有“My Code”、“你的代碼”或“他/她的代碼”，只有“我們的代碼”。
• 只有水平上的差距，沒有層級上的差異。兩人結對，儘管可能大家的層級資曆不同，但不管在分析、設計或編碼上，雙方都擁有平等的決策權利。

團隊精神是好多地方都強調的一個精神，最小的團隊就是一對一的二人團隊了，培養團隊精神從結對程式設計開始吧。社會生活中人與人相處最重要的是誠信，有同理心，互利。結對程式設計中大家會出現分歧，如何更有效地合作要做到對事不對人。

（四）版本控制

XP的集體所有制意味著每個人都對所有的代碼負責；這一點，反過來又意味著每個人都可以更改代碼的任意部分。結對程式設計對這一實踐貢獻良多：藉由在不同的結對中工作，所有的程式員都能看到完全的代碼。集體所有制的一個主要優勢是提升了開發程式的速度，因為一旦代碼中出現錯誤，任何程式員都能修正它。 這意味著代碼要放到一個大家都能方便擷取的地方，我們叫代碼倉庫。這引出另外一個話題叫版本控制（Version Control）。

不論是對於團隊還是個體，版本控制都提供了很多好處。

• 版本控制提供項目級的      undo（撤銷）      功能：      沒有什麼事情是終結版本， 任何錯誤必須很容易復原。 假設你在使用世界上最複雜的文文書處理系統。 它具備了所有的能想到的功能，就是沒有支援 DELETE（刪除） 鍵。想象你打字的時候得多麼的謹慎和緩慢吧，      特別是一篇超大的文檔的快臨近末尾的時候， 一個不小心就要重頭再來（試想你選中所有的文字， 不小心按了 DELETE 鍵， 因為沒有撤銷功能，只好重新錄入）。編輯文字和版本控制相同，任何時候都需要復原，無論是一個小時， 一天， 還是一周， 這讓你的團隊工作自由快速的工作， 而且對於修正錯誤也非常自信。
• 版本控制允許多人在同一代碼上工作，      只要遵守一定的控制原則就行。 再也不會發生諸如一個人覆蓋了另一個人編輯的代碼，導致那個人的修改無效這樣的情況。
• 版本控制系統儲存了過去所作的修改的記錄。如果你遭遇到一些驚訝的代碼，通過版本控制系統可以很容易找出是誰乾的， 修改了什麼， 修改的時間， 如果幸運的話，還能找出原因。
• 版本控制系統還支援在主線上開發的同時發布多個軟體版本。在軟體發布的時候也不需要整個團隊的停止工作，不需要凍結代碼。
• 版本控制也是項目級的時間機器，你可以選擇任何一個時間， 精確地查看項目在當時的情況。 這對研究非常有用， 也是重現以前某個有問題的發布版本的基礎

• （五）重構

  我們先看看重構的概念:

  重構(Refactor)，就是在不改變軟體外部行為的基礎上，改變軟體內部的結構，使其更加易於閱讀、易於維護和易於變更 。

  重構中一個非常關鍵的前提就是“不改變軟體外部行為”，它保證了我們在重構原有系統的同時，不會為原系統帶來新的BUG，以確保重構的安全。如何保證不改變軟體外部行為？重構後的代碼要能通過單元測試。如何使其更加易於閱讀、易於維護和易於變更 ？設計模式給出了重構的目標。

• 六）實踐項目

  1、項目簡介：實現五子棋遊戲的可視化與運用。

• 代碼：
• 運行：

 

（八）實驗總結

  通過這次實驗學習到重構的raname：如何修改名稱。以前在編程式時名稱不小心打錯，或者是需要對名稱進行修改使它更有意義時，現在可以快捷簡便的進行修改。我覺得對以後代碼的編寫特別的實用，有意義。在實驗中我也遇到了很多的問題，比如在進行重構的封裝功能時，因為沒有選中age、name、id使代碼封裝失敗，不過通過請教做完實驗的同學最後問題還是迎刃而解了。

 

實驗三 java敏捷開發與XP