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