XP方法學習總結及對小組開發的思考
2024-07-21 02:17:09
供稿:網友
 
xp方法的許多特點都能在目前公司的開發過程中找到影子,在閱讀了相關資料后,可以從中得到很多的收獲,下面將扼要的列出一些我所認為很有幫助的關鍵點。 
 xp中強調每個人對代碼都有權利修改,這樣的方式其實在小組內部已經被默許了,在小組中以后應該貫徹這樣的原則,鼓勵每個成員對整個系統的代碼進行合理的修改,根據個人體會,這樣的修改一般都是有利的,即使會導致一些小的影響,但一般都能很快克服。 
 強調時間的利用,實際上在xp方法中反復強調的是,一些正規化的討論和大量的文檔某種意義上來說是一種無用功,想一想,我們有多少的時間被這樣的無用功所吞噬?當然這樣的原則并非提倡無文檔化,文檔的產生要根據具體環境來定,我的觀點是,很難確定一種文檔固定的模式,文檔的作用是解決一些信息溝通中的差異,例如目前為了解決同用戶的交流,就很有必要提供一個簡單的幾頁紙的系統說明,這一點不在這里展開。
 另外xp強調貫穿在開發過程中的簡單原則,強調“輕裝上陣”,因此在我們的項目中也要在每個成員的思想中牢牢的貫徹這樣的思想,一段時間用來編碼、寫注釋、設計、測試都是有效的,這也是印證xp中一個基本的原則:代碼能夠傳遞所有的信息,為代碼工作是最直接也是與產品聯系最緊密的工作,由此引發的思考是,設計是為了更好的編碼、注釋是為了提高代碼的可閱讀性、測試是為了提高代碼的正確性,所有這一切都是直接或間接的為代碼工作,在實際中,很多人都發現,一些不實用的文檔重復使用頻率是相當低的,因此,這一點原則對我的啟發相當大,也更能讓我把重點放在編碼、設計和測試上,也能打消我以前存在的一些疑惑:如果不編寫漂亮和規范化的文檔就說明了我們小組的開發效率是低下的,進而也說明我們的產品質量是不能保證的,進而也說明我們公司的競爭力是低下的?比如對一些關鍵的編程任務抽取一段時間同小組成員成對編寫,在一個人編寫代碼的過程中,另一個人利用紙、筆或其他工具進行設計和構思、或者一個人編碼、另一個人查找一些相關的資料,設計測試用例子等,至于對測試用例子的規范化、對設計的文檔化等等問題其實是相當耗費時間的,可以將其份量減輕。xp中提倡開發人員的尊重及某種程度上的自由化,其實這樣的思想也是符合軟件開發行業的特點的,軟件開發是一個腦力密集的工作,開發人員的個人因素相當大程度上影響著軟件產品的質量,盡可能根據開發人員的愛好興趣營造舒適的工作環境其實也是間接的在提高軟件產品的質量,況且還有xp中如此強調的嚴格測試在進行監督,管理人員完全可以放心的等待合格和健壯的軟件產品。記得看過一篇文章介紹,有了word之后發現有時候工作效率反倒降低了,以為使用者把大量的時間花在如何做出一份漂亮的文檔。我個人認為文檔的作用是對某種約定或結論的文字記錄,以便可以隨時查閱、提醒。比如開發規范、需求分析等等。這一點和作者的“文檔的作用是解決一些信息溝通中的差異”有一些差異。有很多東西我們在得到一致的結論后如果沒有文檔作為記錄的話很容易遺忘,這一點和程序中的注釋是一樣的。但文檔是否要嚴格的按照程序規范去做就可以靈活掌握了。正規化的討論我認為很有必要,我理解的正規化的討論是有明確的議題,參與討論的人也應該對議題有一個事先的了解,在得出結論后需要有相關的文檔既要進行記錄。最重要的問題是正規化的討論可以解決一些重要的問題。一般性的討論如技術、設計等方面的討論可以隨時進行,但也應該視情況對結論進行記錄。
 2.“一段時間用來編碼、寫注釋、設計、測試都是有效的”。我個人認為這句話更適合用在基本框架已經確定,只是個體部分具體如何實現的時候才使用。如果客觀條件許可最好還是將整個結構、框架等大的東西事先確定,否則很難保證邊做邊想的情況下不會出現問題。
 3.“至于xp中反復強調的成對編程,我也深深的被其中所體現的優點所打動”。成對編程的好處是可以用兩個人考慮同樣的問題來盡量減少思維的盲點,同時兩個人對同樣的問題達成共識后可以并行進行多項工作,“或者一個人編碼、另一個人查找一些相關的資料,設計測試用例子等”,實際上是通過增加人員配置來縮短開發周期。而“在一個人編寫代碼的過程中,另一個人利用紙、筆或其他工具進行設計和構思”,如果兩個人不能達成共識并銜接得當的話,成對編程的作用將要大打折扣。
 4.“至于對測試用例子的規范化、對設計的文檔化等等問題其實是相當耗費時間的,可以將其份量減輕”,這我認為是必要的。如果系統復雜程度比較小,那么做這些工作也花不了多少時間。如果系統復雜程度高不這樣做是死路一條。但這些工作的成果是體現在其實際效用上,而不是形式上的規范化、標準化上。這方面的掌握上就需要豐富的經驗了。
 5.“xp中提倡開發人員的尊重及某種程度上的自由化,其實這樣的思想也是符合軟件開發行業的特點的”。這種觀點還是贊同的,但協作開發必須要有規章制度,否則項目將進入到混亂的狀態,也就無法實現對開發人員的尊重.
歡迎經