【文章內容簡介】 年 1月20日）在北京郵電大學軟件學院學習期間，我積極參加學校組織的前沿課題講座和各大企業(yè)舉辦的新技術講座，下邊分幾個方面談一談對敏捷開發(fā)、自動化測試、大數(shù)據(jù)講座的體會：一、敏捷開發(fā)最近一段時間以來，很多人開始談論敏捷開發(fā)、研究敏捷開發(fā)，那么究竟什么才是敏捷開發(fā)呢? 簡單的說，敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。在敏捷開發(fā)中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。敏捷開發(fā)是由一些業(yè)界專家針對一些企業(yè)現(xiàn)狀提出了一些讓軟件開發(fā)團隊具有快速工作、響應變化能力的價值觀和原則，并于2001初成立了敏捷聯(lián)盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。敏捷開發(fā)(agile development)概念從2004年初開始廣為流行。Bailar非常支持這一理論，他采取了“敏捷方式”組建團隊：Capital One的“敏捷團隊”包括3名業(yè)務人員、兩名操作人員和5～7名IT人員，其中包括1個業(yè)務信息指導(實際上是業(yè)務部門和IT部門之間的“翻譯者”)。另外，還有一個由項目經理和至少80名開發(fā)人員組成的團隊。這些開發(fā)人員都曾被Bailar送去參加過“敏捷開發(fā)”的培訓，具備相關的技能。每個團隊都有自己的敏捷指導(Bailar聘用了20個敏捷指導)，他的工作是關注流程并提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發(fā)有規(guī)律地停頓在9周開發(fā)過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各“敏捷團隊”，這種方式在“敏捷開發(fā)”中叫“蜂巢式(swarming)”，所有過程由一名項目經理控制。為了檢驗這個系統(tǒng)的效果，Bailar將項目拆分，從舊的“瀑布式”開發(fā)轉變?yōu)椤安⒘惺健遍_發(fā)，形成了“敏捷開發(fā)”所倡導的精干而靈活的開發(fā)團隊，并將開發(fā)階段分成30天一個周期，進行“沖刺”每個沖刺始于一個啟動會議，到下個沖刺前結束。在Bailar將其與傳統(tǒng)的開發(fā)方式做了對比后，他感到非常興奮“敏捷開發(fā)”使開發(fā)時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量?！安贿^，有些需求不能用敏捷開發(fā)來處理?！?Bailar承認，“敏捷開發(fā)”也有局限性，比如對那些不明確、優(yōu)先權不清楚的需求或處于“較快、較便宜、較優(yōu)”的三角架構中卻不能排列出三者優(yōu)先級的需求。此外，他覺得大型項目或有特殊規(guī)則的需求的項目，更適宜采用傳統(tǒng)的開發(fā)方式。盡管描述需求一直是件困難的事，但經過陣痛之后，需求處理流程會讓CIO受益匪淺。二、敏捷開發(fā)模式內容TestDriven Development，測試驅動開發(fā)，它是敏捷開發(fā)的最重要的部分。在ThoughtWorks，實現(xiàn)任何一個功能都是從測試開始，首先對業(yè)務需求進行分析，分解為一個一個的Story，記錄在Story Card上。然后兩個人同時坐在電腦前面，一個人依照Story，從業(yè)務需求的角度來編寫測試代碼，另一個人看著他并且進行思考，如果有不同的意見就會提出來進行討論，直到達成共識，這樣寫出來的測試代碼就真實反映了業(yè)務功能需求。接著由另一個人控制鍵盤，編寫該測試代碼的實現(xiàn)。如果沒有測試代碼，就不能編寫功能的實現(xiàn)代碼。先寫測試代碼，能夠讓開發(fā)人員明確目標，就是讓測試通過。Continuous Integration，持續(xù)集成。在以往的軟件開發(fā)過程中，集成是一件很痛苦的事情，通常很長時間才會做一次集成，這樣的話，會引發(fā)很多問題，比如build未通過或者單元測試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內集成十幾次甚至幾十次，如此頻繁的集成能盡量減少沖突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯誤。一次集成要做哪些事情呢？它至少包括：獲得所有源代碼；編譯源代碼；運行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最后發(fā)送報告。當然也會做一些其它的任務，比如說代碼分析、測試覆蓋率分析等等。在我們公司里，開發(fā)人員的桌上有一個火山燈用來標志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。有很多很多的書用來介紹重構，最著名的是Martin的《重構》，Joshua的《從重構到模式》等。重構是在不改變系統(tǒng)外部行為下，對內部結構進行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴展。在以往開發(fā)中，通常是在有需求過來，現(xiàn)在的系統(tǒng)架構不容易實現(xiàn)，從而對原有系統(tǒng)進行重構；或者在開發(fā)過程中有剩余時間了，對現(xiàn)在代碼進行重構整理。但是在敏捷開發(fā)中，重構貫穿于整個開發(fā)流程，每一次開發(fā)者check in代碼之前，都要對所寫代碼進行重構，讓代碼達到clean code that works。值得注意的是，在重構時，每一次改變要盡可能小，用單元測試來保證重構是否引起沖突，并且不只是對實現(xiàn)代碼進行重構，如果測試代碼中有重復，也要對它進行重構。PairProgramming，結對編程。在敏捷開發(fā)中，做任何事情都是Pair的，包括分析、寫測試、寫實現(xiàn)代碼或者重構。Pair做事有很多