20155314 2016-2017-2 《Java程序設計》實驗三敏捷開發與XP實踐

時間 2019-11-30

標籤 Java程序設計實驗敏捷開發實踐欄目 Windows 简体版

原文原文鏈接

20155314 2016-2017-2 《Java程序設計》實驗三敏捷開發與XP實踐

實驗內容

XP基礎html
XP核心實踐java
相關工具git

實驗知識點總結

（一）敏捷開發與XP

軟件工程：把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程
軟件工程包括如下領域：
- 軟件需求分析
- 軟件設計
- 軟件構建
- 軟件測試
- 軟件維護
軟件開發流程：人們在開發、運營、維護軟件的過程當中有不少技術、作法、習慣和思想體系。軟件工程把這些相關的技術和過程統一到一個體系中，叫「軟件開發流程」
軟件開發流程的目的：爲了提升軟件開發、運營、維護的效率，並提升軟件的質量、用戶滿意度、可靠性和軟件的可維護性
常見公式：
- 軟件工程=開發流程+工具
- 軟件=程序+軟件工程和軟件企業=軟件+商業模式(鄒欣老師給出)
常見開發流程：
- RUP(Rational Unified Process)
- PSP(Personal Software Process )
- TSP(Team Software Process )
- Agile Process
- ……
敏捷開發（Agile Development）：是一種以人爲核心、迭代、按部就班的開發方法
極限編程(eXtreme Programming，XP)：是一種全新而快捷的軟件開發方法。XP團隊使用現場客戶、特殊計劃方法和持續測試來提供快速的反饋和全面的交流：
- XP是以開發符合客戶須要的軟件爲目標而產生的一種方法論
- XP是一種以實踐爲基礎的軟件工程過程和思想
- XP認爲代碼質量的重要程度超出人們通常所認爲的程度
- XP特別適合於小型的有責任心的、自覺自勵的團隊開發需求不肯定或者迅速變化的軟件
XP軟件開發是什麼樣的經過XP準則來表達：
- 溝通：XP認爲項目成員之間的溝通是項目成功的關鍵，並把溝通看做項目中間協調與合做的主要推進因素。
- 簡單：XP假定將來不能可靠地預測，在如今考慮它從經濟上是不明智的，因此不該該過多考慮將來的問題而是應該集中力量解決燃眉之急。
- 反饋：XP認爲系統自己及其代碼是報告系統開發進度和狀態的可靠依據。系統開發狀態的反饋能夠做爲一種肯定系統開發進度和決定系統下一步開發方向的手段。
- 勇氣：表明了XP認爲人是軟件開發中最重要的一個方面的觀點。在一個軟件產品的開發中人的參與貫穿其整個生命週期，是人的勇氣來排除困境，讓團隊把局部的最優拋之腦後，達到更重大的目標。代表了XP對「人讓項目取得成功」的基本信任態度。
一項實踐在XP環境中成功使用的依據經過XP的法則呈現，包括：
- 快速反饋
- 假設簡單性
- 遞增更改
- 提倡更改
- 優質工做
XP軟件開發的基石是XP的活動，包括：
- 編碼
- 測試
- 傾聽
- 設計

（二）編碼標準

編寫代碼一個重要的認識是「程序大多時候是給人看的」，編程標準使代碼更容易閱讀和理解，甚至能夠保證其中的錯誤更少。
編程標準包含：
- 具備說明性的名字
- 清晰的表達式
- 直截了當的控制流
- 可讀的代碼和註釋
- 在追求這些內容時一致地使用某些規則和慣用法的重要性
編碼標準中的版式就是一個很好的例子，版式雖然不會影響程序的功能，但會影響可讀性。程序的版式追求清晰、美觀，是程序風格的重要因素。
Java中的通常的命名規則：
- 要體現各自的含義
- 包、類、變量用名詞
- 方法名用動賓
- 包名所有小寫，如：io，awt
- 類名第一個字母要大寫，如：HelloWorldApp
- 變量名第一個字母要小寫，如：userName
- 方法名第一個字母要小寫：setName
- ...

（三）結對編程

結對編程是XP中的重要實踐。在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔等。程序員

結對編程中有兩個角色：
- 駕駛員（Driver）是控制鍵盤輸入的人。
- 領航員（Navigator）起到領航、提醒的做用。
如何結對編程：
- 駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。
- 領航員：審閱駕駛員的文檔、駕駛員對編碼等開發流程的執行；考慮單元測試的覆蓋率；思考是否須要和如何重構；幫助駕駛員解決具體的技術問題。
- 駕駛員和領航員不斷輪換角色，不要連續工做超過一小時，每工做一小時休息15分鐘。領航員要控制時間。
- 主動參與。任何一個任務都首先是兩我的的責任，也是全部人的責任。沒有「個人代碼」、「你的代碼」或「他/她的代碼」，只有「咱們的代碼」。
- 只有水平上的差距，沒有級別上的差別。兩人結對，儘管可能你們的級別資歷不一樣，但無論在分析、設計或編碼上，雙方都擁有平等的決策權利。
結對編程中出現分歧，應對事不對人

（四）版本控制（Version Control）

代碼倉庫
版本控制的好處：
- 版本控制提供項目級的 undo（撤銷）功能：沒有什麼事情是終結版本，任何錯誤必須很容易回滾。假設你在使用世界上最複雜的文字處理系統。它具有了全部的能想到的功能，就是沒有支持 DELETE（刪除）鍵。想象你打字的時候得多麼的謹慎和緩慢吧，特別是一篇超大的文檔的快臨近末尾的時候，一個不當心就要重頭再來（試想你選中全部的文字，不當心按了 DELETE 鍵，由於沒有撤銷功能，只好從新錄入）。編輯文字和版本控制相同，任什麼時候候都須要回滾，不管是一個小時，一天，仍是一週，這讓你的團隊工做自由快速的工做，並且對於修正錯誤也很是自信。
- 版本控制容許多人在同一代碼上工做，只要遵照必定的控制原則就行。不再會發生諸如一我的覆蓋了另外一我的編輯的代碼，致使那我的的修改無效這樣的狀況。
- 版本控制系統保存了過去所做的修改的歷史記錄。若是你遭遇到一些驚訝的代碼，經過版本控制系統能夠很容易找出是誰幹的，修改了什麼，修改的時間，若是幸運的話，還能找出緣由。
- 版本控制系統還支持在主線上開發的同時發佈多個軟件版本。在軟件發佈的時候也不須要整個團隊的中止工做，不須要凍結代碼。
- 版本控制也是項目級的時間機器，你能夠選擇任何一個時間，精確地查看項目在當時的狀況。這對研究很是有用，也是重現之前某個有問題的發佈版本的基礎。

（五）重構

重構的概念：算法

重構(Refactor)，就是在不改變軟件外部行爲的基礎上，改變軟件內部的結構，使其更加易於閱讀、易於維護和易於變動。express
重構中一個很是關鍵的前提就是「不改變軟件外部行爲」，它保證了咱們在重構原有系統的同時，不會爲原系統帶來新的BUG，以確保重構的安全。
- 如何保證不改變軟件外部行爲：重構後的代碼要能經過單元測試。
- 如何使其更加易於閱讀、易於維護和易於變動：設計模式給出了重構的目標。
修改軟件的四種動機：
- 增長新功能
- 原有功能有BUG
- 改善原有程序的結構
- 優化原有系統的性能
須要重構的地方：有臭味道（Bad Smell）的代碼——Duplicated Code(重複的代碼)
- 最單純的Duplicated Code就是［同一個class內的兩個方法含有相同表達式(expression)］。這時候你須要作的就是採用Extract Method提煉出重複的代碼，而後讓這兩個地點都調用被提煉出來的那一段代碼。
- 另外一種常見狀況就是[兩個互爲兄弟(sibling)的subclasses內含有相同表達式]。要避免這種狀況，只須要對兩個classes都使用Extract Method，而後再對被提煉出的代碼使用Pull Up Method，將它推入superclass內。
- 若是代碼之間只是相似，並不是徹底相同，那麼就得運用Extract Method將類似部分和差別部分割開，構成單獨一個方法。而後你可能發現或許能夠運用Form Template Method得到一個Template Method設計模式。
- 若是有些方法以不一樣的算法作相同的事，你能夠擇定其中較清晰的一個，並使用Substitute Algorithm將其它方法的算法替換掉。
- 若是兩個絕不相關的classes內出現Duplicaded Code，你應該考慮對其中一個使用Extract Class，將重複代碼提煉到一個獨立class中，而後在另外一個class內使用這個新class。可是，重複代碼所在的方法也可能的確只應該屬於某個class，另外一個class只能調用它，抑或這個方法可能屬於第三個class，而另兩個classes應該引用這第三個class。你必須決定這個方法放在哪兒最合適，並確保它被安置後就不會再在其它任何地方出現。
一個完整的重構流程：
1. 從版本控制系統代碼庫中Check out code
2. 讀懂代碼（包括測試代碼）
3. 發現bad smell
4. Refactoring
5. 運行全部的Unit Tests
6. 往代碼庫中Check in code
在IDEA下重構實踐以下圖：

編程