2017-2018-2 20165228 實驗三《敏捷開發與XP實踐》實驗報告
相關知識點
(一)敏捷開發與XP
- 經過 XP準則來表達:
- 溝通 :XP認爲項目成員之間的溝通是項目成功的關鍵,並把溝通看做項目中間協調與合做的主要推進因素。
- 簡單 :XP假定將來不能可靠地預測,在如今考慮它從經濟上是不明智的,因此不該該過多考慮將來的問題而是應該集中力量解決燃眉之急。
- 反饋 :XP認爲系統自己及其代碼是報告系統開發進度和狀態的可靠依據。系統開發狀態的反饋能夠做爲一種肯定系統開發進度和決定系統下一步開發方向的手段。
- 勇氣:表明了XP認爲人是軟件開發中最重要的一個方面的觀點。在一個軟件產品的開發中人的參與貫穿其整個生命週期,是人的勇氣來排除困境,讓團隊把局部的最優拋之腦後,達到更重大的目標。代表了XP對「人讓項目取得成功」的基本信任態度。
- 一項實踐在XP環境中成功使用的依據經過XP的法則呈現,包括:快速反饋、假設簡單性、遞增更改、提倡更改、優質工做。
XP軟件開發的基石是XP的活動,包括:編碼、測試、傾聽、設計。html
(二)編碼標準
- 編程標準使代碼更容易閱讀和理解,甚至能夠保證其中的錯誤更少。編程標準包含:具備說明性的名字、清晰的表達式、直截了當的控制流、可讀的代碼和註釋,以及在追求這些內容時一致地使用某些規則和慣用法的重要性。
- 代碼標準中很重要的一項是如何給包、類、變量、方法等標識符命名,能很好的命名可讓本身的代碼立立刻升一個檔次。Java中的通常的命名規則有:
- 要體現各自的含義
- 包、類、變量用名詞
- 方法名用動賓
- 包名所有小寫,如:io,awt
- 類名第一個字母要大寫,如:HelloWorldApp
- 變量名第一個字母要小寫,如:userName
- 方法名第一個字母要小寫:setName
標識符的長度遵循「min-length && max-information」的原則git
(三)結對編程
- 結對編程是XP中的重要實踐。在結對編程模式下,一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前,面對同一個顯示器,使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析,一塊兒設計,一塊兒寫測試用例,一塊兒編碼,一塊兒作單元測試,一塊兒作集成測試,一塊兒寫文檔等。
- 結對編程中有兩個角色:
- 駕駛員(Driver)是控制鍵盤輸入的人。
- 領航員(Navigator)起到領航、提醒的做用。
- 如何結對編程,爲什麼要結對編程,你們參考一下結對編程和兩人合做 ,重點是:
- XP的集體全部制意味着每一個人都對全部的代碼負責;這一點,反過來又意味着每一個人均可以更改代碼的任意部分。結對編程對這一實踐貢獻良多:藉由在不一樣的結對中工做,全部的程序員都能看到徹底的代碼。集體全部制的一個主要優點是提高了開發程序的速度,由於一旦代碼中出現錯誤,任何程序員都能修正它。
這意味着代碼要放到一個你們都能方便獲取的地方,咱們叫代碼倉庫。這引出另一個話題叫版本控制(Version Control)。算法
不管是對於團隊仍是個體,版本控制都提供了不少好處。express
- 版本控制提供項目級的 undo(撤銷) 功能: 沒有什麼事情是終結版本, 任何錯誤必須很容易回滾。 假設你在使用世界上最複雜的文字處理系統。 它具有了全部的能想到的功能,就是沒有支持 DELETE(刪除) 鍵。想象你打字的時候得多麼的謹慎和緩慢吧, 特別是一篇超大的文檔的快臨近末尾的時候, 一個不當心就要重頭再來(試想你選中全部的文字, 不當心按了 DELETE 鍵, 由於沒有撤銷功能,只好從新錄入)。編輯文字和版本控制相同,任什麼時候候都須要回滾,不管是一個小時, 一天, 仍是一週, 這讓你的團隊工做自由快速的工做, 並且對於修正錯誤也很是自信。
- 版本控制容許多人在同一代碼上工做, 只要遵照必定的控制原則就行。 不再會發生諸如一我的覆蓋了另外一我的編輯的代碼,致使那我的的修改無效這樣的狀況。
- 版本控制系統保存了過去所做的修改的歷史記錄。若是你遭遇到一些驚訝的代碼,經過版本控制系統能夠很容易找出是誰幹的, 修改了什麼, 修改的時間, 若是幸運的話,還能找出緣由。
- 版本控制系統還支持在主線上開發的同時發佈多個軟件版本。在軟件發佈的時候也不須要整個團隊的中止工做,不須要凍結代碼。
- 版本控制也是項目級的時間機器,你能夠選擇任何一個時間, 精確地查看項目在當時的狀況。 這對研究很是有用, 也是重現之前某個有問題的發佈版本的基礎。
- git使用
git status
查看一下代碼狀態,顯示有未跟蹤的代碼,並建議用編程
git add <file>
添加
git push
(五)重構
- 重構(Refactor),就是在不改變軟件外部行爲的基礎上,改變軟件內部的結構,使其更加易於閱讀、易於維護和易於變動 。
- 重構中一個很是關鍵的前提就是「不改變軟件外部行爲」,它保證了咱們在重構原有系統的同時,不會爲原系統帶來新的BUG,以確保重構的安全。如何保證不改變軟件外部行爲?重構後的代碼要能經過單元測試。如何使其更加易於閱讀、易於維護和易於變動 ?設計模式給出了重構的目標
- 增長新功能;
- 原有功能有BUG;
- 改善原有程序的結構;
- 優化原有系統的性能 。
- 最單純的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。你必須決定這個方法放在哪兒最合適,並確保它被安置後就不會再在其它任何地方出現。
- 給類、包、方法、變量更名字
Rename
- 當出現代碼重複問題時,正常的重構可使用Extract Method
Extract Method
-專門的tostring()方法:設計模式
Generate toString()
實驗內容
(一)敏捷開發與XP實踐-1
檢查點要求:
public class CodeStandard {
public static void main(String [] args){
StringBuffer buffer = new StringBuffer();
buffer.append('S');
buffer.append("tringBuffer");
System.out.println(buffer.charAt(1));
System.out.println(buffer.capacity());
System.out.println(buffer.indexOf("tring"));
System.out.println("buffer = " + buffer.toString());
if(buffer.capacity()<20)
buffer.append("1234567");
for(int i=0; i<buffer.length();i++)
System.out.println(buffer.charAt(i));
}
}
相關截圖:
鼠標選擇code
——>Reformat Code
安全
(二)敏捷開發與XP實踐-2
檢查點要求:
![](http://static.javashuo.com/static/loading.gif)
(三)敏捷開發與XP實踐-3
檢查點要求:
參考實驗三 敏捷開發與XP實踐 http://www.cnblogs.com/rocedu/p/4795776.html, Eclipse的內容替換成IDEA
完成重構內容的練習,下載搭檔的代碼,至少進行三項重構,提交重構後代碼的截圖,加上本身的學號水印。提交搭檔的碼雲項目連接。
相關截圖:
標識符可使用Refactor
-->`Rename
來修改
- 實現部分無心義變量名的替換以及省略了一些多餘的變量以節省內存空間。
將print內容經過extract method
新建private static String
方法來實現
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
(四)敏捷開發與XP實踐-4
檢查點要求:
PSP(Personal Software Process)時間
需求分析 |
50 |
17% |
設計 |
60 |
20% |
代碼實現 |
120 |
40% |
測試 |
40 |
13% |
分析總結 |
30 |
10% |