【文章內(nèi)容簡介】 如build未通過或者單元測試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內(nèi)集成十幾次甚至幾十次，如此頻繁的集成能盡量減少沖突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯誤。一次集成要做哪些事情呢？它至少包括：獲得所有源代碼；編譯源代碼；運行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最后發(fā)送報告。當然也會做一些其它的任務(wù)，比如說代碼分析、測試覆蓋率分析等等。在我們公司里，開發(fā)人員的桌上有一個火山燈用來標志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。有很多很多的書用來介紹重構(gòu)，最著名的是Martin的《重構(gòu)》，Joshua的《從重構(gòu)到模式》等。重構(gòu)是在不改變系統(tǒng)外部行為下，對內(nèi)部結(jié)構(gòu)進行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴展。在以往開發(fā)中，通常是在有需求過來，現(xiàn)在的系統(tǒng)架構(gòu)不容易實現(xiàn)，從而對原有系統(tǒng)進行重構(gòu)；或者在開發(fā)過程中有剩余時間了，對現(xiàn)在代碼進行重構(gòu)整理。但是在敏捷開發(fā)中，重構(gòu)貫穿于整個開發(fā)流程，每一次開發(fā)者check in代碼之前，都要對所寫代碼進行重構(gòu)，讓代碼達到clean code that works。值得注意的是，在重構(gòu)時，每一次改變要盡可能小，用單元測試來保證重構(gòu)是否引起沖突，并且不只是對實現(xiàn)代碼進行重構(gòu)，如果測試代碼中有重復，也要對它進行重構(gòu)。PairProgramming，結(jié)對編程。在敏捷開發(fā)中，做任何事情都是Pair的，包括分析、寫測試、寫實現(xiàn)代碼或者重構(gòu)。Pair做事有很多好處，兩個人在一起探討很容易產(chǎn)生思想的火花，也不容易走上偏路。Stand up，站立會議。每天早上，項目組的所有成員都會站立進行一次會議，由于是站立的，所以時間不會很長，一般來說是1520分鐘。會議的內(nèi)容并不是需求分析、任務(wù)分配等，而是每個人都回答三個問題：？？ ？站立會議讓團隊進行交流，彼此相互熟悉工作內(nèi)容，如果有人曾經(jīng)遇到過和你類似的問題，那么在站立會議后，他就會和你進行討論。Frequent Releases，小版本發(fā)布。在敏捷開發(fā)中，不會出現(xiàn)這種情況，拿到需求以后就閉門造車，直到最后才將產(chǎn)品交付給客戶，而是盡量多的產(chǎn)品發(fā)布，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到發(fā)布的產(chǎn)品進行試用，而我們可以從客戶那得到更多的反饋來改進產(chǎn)品。正因為發(fā)布頻繁，每一個版本新增的功能簡單，不需要復雜的設(shè)計，這樣文檔和設(shè)計就在很大程度上簡化了。又因為簡單設(shè)計，沒有復雜的架構(gòu)，所以客戶有新的需求或者需求進行變動，也能很快的適應(yīng)。Minimal Documentation，較少的文檔。其實敏捷開發(fā)中并不是沒有文檔，而是有大量的文檔，即測試。這些測試代碼真實的反應(yīng)了客戶的需求以及系統(tǒng)API的用法，如果有新人加入團隊，最快的熟悉項目的方法就是給他看測試代碼，而比一邊看著文檔一邊進行debug要高效。如果用書面文檔或者注釋，某天代碼變化了，需要對這些文檔進行更新。一旦忘記更新文檔，就會出現(xiàn)代碼和文檔不匹配的情況，這更加會讓人迷惑。而在敏捷中并不會出現(xiàn)，因為只有測試變化了，代碼才會變化，測試是真實反應(yīng)代碼的。這時有人會問：代碼不寫注釋行嗎？一般來說好的代碼不是需要大量的注釋嗎？其實簡單可讀的代碼才是好的代碼，既然簡單可讀了，別人一看就能夠看懂，這時候根本不需要對代碼進行任何注釋。若你覺得這段代碼不加注釋的話別人可能看不懂，就表示設(shè)計還不夠簡單，需要對它進行重構(gòu)。Collaborative Focus，以合作為中心，表現(xiàn)為代碼共享。在敏捷開發(fā)中，代碼是歸團隊所有而不是哪些模塊的代碼屬于哪些人，每個人都有權(quán)利獲得系統(tǒng)任何一部分的代碼然后修改它，每個人都能夠?qū)@部分代碼重構(gòu)而不需要征求代碼作者的同意。這樣每個人都能熟悉系統(tǒng)的代碼，即使團隊的人員變動，也沒有風險。Customer Engagement，現(xiàn)場客戶。敏捷開發(fā)中，客戶是與開發(fā)團隊一起工作的，團隊到客戶現(xiàn)場進行開發(fā)或者邀請客戶到團隊公司里來開發(fā)。如果開發(fā)過程中有什么問題或者產(chǎn)品經(jīng)過一個迭代后，能夠以最快速度得到客戶的反饋。敏捷開發(fā)過程與傳統(tǒng)的開發(fā)過程有很大不同，在這過程中，團隊是有激情有活力的，能夠適應(yīng)更大的變化，做出更高質(zhì)量的軟件。三、自動化測試Automated Testing，自動化測試。為了減小人力或者重復勞動，所有的測試包括單元測試、功能測試或集成測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發(fā)語言、自動化測試工具，能夠編寫自動化測試腳本或者用工具錄制。在自動化測試過程中，UI的自動化測試實施難度比后臺程序的自動化要大，那么UI自動化測試是怎么做的呢？首先需要用一個持續(xù)集成的工具hudson作為一個顆粒度比較粗的測試用例管理工具，hudson作為自動化測試的主心骨，QA們可以在hudson上觸發(fā)自動化測試的運行，運行完了以后可以看到測試結(jié)果，并且，利用了hudson的分布式結(jié)構(gòu)，由多個測試機來執(zhí)行測試，達到了很好的資源調(diào)配。對瀏覽器的控制方面，用了Selenium，會上沒有問UI是否利用了Selenium的多瀏覽器支持，從演示上來看應(yīng)該只做的Firefox的。他們的分工很明確，分了專門做功能測試的QA和專門做自動化測試工具開發(fā)的SDET，SDET主要是負責寫RUBY代碼，封裝并且暴露了一些通用的方法給QA使用，并且同時使用了Cucumber作為一個DSL，QA是用Cucumber來做自動化測試的一些描述，Cucumber的作用就是對功能測試的QA屏蔽了底層RUBY腳本，對上就是“翻譯”功能測試QA的意圖，“翻譯”成RUBY。優(yōu)點在于：分開了自動化測試工具開發(fā)和自動化測試實施；使用了大量開源工具，提高效率；在測試過程中我將這個方式加以運用，提高了測試技術(shù)。自動化測試是軟件測試發(fā)展的一個方向。很多人都認為做測試，懂得自動化測試是很重要的。我之前用QTP的時候，給自己最大的感觸就是錄制腳本和調(diào)試腳本的時間太長了。通過一些講座和交流，我對自動化測試和腳本的錄制修改技巧慢慢熟知，大大提高了自動化測試設(shè)計的效率。測試是一個思考的過程，自動化測試是測試發(fā)展的必然趨勢，所以在自動化測試的運用之中我還是有很多需要學習的內(nèi)容。四、大數(shù)據(jù) 現(xiàn)在，當數(shù)據(jù)的積累量足夠大的時候，量變引起了質(zhì)變，“大數(shù)據(jù)”通過對海量數(shù)據(jù)有針對性的分析，賦予了互聯(lián)網(wǎng)“智商”，這使得互聯(lián)網(wǎng)的作用，從簡單的數(shù)據(jù)交流和信息傳遞，上升到基于海量數(shù)據(jù)的分析，一句話“他開始思考了”。簡言之，大數(shù)據(jù)就是將碎片化的海量數(shù)據(jù)在一定的時間內(nèi)完成篩選、分析，并整理成為有用的資訊，幫助用戶完成決策。借助大數(shù)據(jù)企業(yè)的決策者可以迅速感知市場需求變化，從而促使他們作出對企業(yè)更有利的決策，使得這些企業(yè)擁有更強的創(chuàng)新力和競爭力。這是繼云計算、物聯(lián)網(wǎng)之后IT產(chǎn)業(yè)又一次顛覆性的技術(shù)變革，對國家治理模式、對企業(yè)的決策、組織和業(yè)務(wù)流程、對個人生活方式都將產(chǎn)生巨大的影響。后工業(yè)社會時代，隨著新興技術(shù)的發(fā)展與互聯(lián)網(wǎng)底層技術(shù)的革新，數(shù)據(jù)正在呈指數(shù)級增長，所有數(shù)據(jù)的產(chǎn)生形式，都是數(shù)字化。如何收集、管理和分析海量數(shù)據(jù)對于企業(yè)從事的一切商業(yè)活動都顯得尤為重要。大數(shù)據(jù)時代是信息化社會發(fā)展必然趨勢，我們只有緊緊跟隨時代發(fā)展的潮流，在技術(shù)上、制度上、價值觀念上做出迅速調(diào)整并牢牢跟進，才能在接下來新一輪的競爭中擺脫受制于人的弱勢境地，才能把握發(fā)展的方向。第三篇：前沿講座心得體會前沿講座心得體會班級：土木132 學號：130711227 姓名：朱玉震20