2.1敏捷開發(fā)就能保障進(jìn)度與質(zhì)量？
敏捷宣言
敏捷開發(fā)的路線
Test-Driven 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ù)需求的角度來編寫測(cè)試代碼，另一個(gè)人看著他并且進(jìn)行思考，如果有不同的意見就會(huì)提出來進(jìn)行討論，直到達(dá)成共識(shí)，這樣寫出來的測(cè)試代碼就真實(shí)反映了業(yè)務(wù)功能需求。接著由另一個(gè)人控制鍵盤，編寫該測(cè)試代碼的實(shí)現(xiàn)。如果沒有測(cè)試代碼，就不能編寫功能的實(shí)現(xiàn)代碼。先寫測(cè)試代碼，能夠讓開發(fā)人員明確目標(biāo)，就是讓測(cè)試通過。
Continuous Integration，持續(xù)集成
在以往的軟件開發(fā)過程中，集成是一件很痛苦的事情，通常很長時(shí)間才會(huì)做一次集成，這樣的話，會(huì)引發(fā)很多問題，比如 build未通過或者單元測(cè)試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內(nèi)集成十幾次甚至幾十次，如此頻繁的集成能盡量減少?zèng)_突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯(cuò)誤。一次集成要做哪些事情呢？它至少包括：獲得所有源代碼、編譯源代碼、運(yùn)行所有測(cè)試，包括單元測(cè)試、功能測(cè)試等；確認(rèn)編譯和測(cè)試是否通過，最后發(fā)送報(bào)告。當(dāng)然也會(huì)做一些其它的任務(wù)，比如說代碼分析、測(cè)試覆蓋率分析等等。在我們公司里，開發(fā)人員的桌上有一個(gè)火山燈用來標(biāo)志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時(shí)候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。在持續(xù)集成上，我們公司使用的是自己開發(fā)的產(chǎn)品CruiseControl。
Refactoring，重構(gòu)
相信大家對(duì)它都很熟悉了，有很多很多的書用來介紹重構(gòu)，最著名的是Martin的《重構(gòu)》，Joshua的《從重構(gòu)到模式》等。重構(gòu)是在不改變系統(tǒng)外部行為下，對(duì)內(nèi)部結(jié)構(gòu)進(jìn)行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴(kuò)展。在以往開發(fā)中，通常是在有需求過來，現(xiàn)在的系統(tǒng)架構(gòu)不容易實(shí)現(xiàn)，從而對(duì)原有系統(tǒng)進(jìn)行重構(gòu)；或者在開發(fā)過程中有剩余時(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è)試來保證重構(gòu)是否引起沖突，并且不只是對(duì)實(shí)現(xiàn)代碼進(jìn)行重構(gòu)，如果測(cè)試代碼中有重復(fù)，也要對(duì)它進(jìn)行重構(gòu)。
Pair-Programming，結(jié)對(duì)編程
在敏捷開發(fā)中，做任何事情都是Pair的，包括分析、寫測(cè)試、寫實(shí)現(xiàn)代碼或者重構(gòu)。Pair做事有很多好處，兩個(gè)人在一起探討很容易產(chǎn)生思想的火花，也不容易走上偏路。在我們公司，還有很多事都是Pair來做，比如Pair學(xué)習(xí)，Pair翻譯，Pair做PPT，關(guān)于這個(gè)話題，有一篇很有名的文章對(duì)它進(jìn)行介紹，名為Pair Programming (結(jié)對(duì)編程)。
Stand up，站立會(huì)議
每天早上，項(xiàng)目組的所有成員都會(huì)站立進(jìn)行一次會(huì)議，由于是站立的，所以時(shí)間不會(huì)很長，一般來說是15-20分鐘。會(huì)議的內(nèi)容并不是需求分析、任務(wù)分配等，而是每個(gè)人都回答三個(gè)問題：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困難？站立會(huì)議讓團(tuán)隊(duì)進(jìn)行交流，彼此相互熟悉工作內(nèi)容，如果有人曾經(jīng)遇到過和你類似的問題，那么在站立會(huì)議后，他就會(huì)和你進(jìn)行討論。
Frequent Releases，小版本發(fā)布
在敏捷開發(fā)中，不會(huì)出現(xiàn)這種情況，拿到需求以后就閉門造車，直到最后才將產(chǎn)品交付給客戶，而是盡量多的產(chǎn)品發(fā)布，一般以周、月為單位。這樣，客戶每隔一段時(shí)間就會(huì)拿到發(fā)布的產(chǎn)品進(jìn)行試用，而我們可以從客戶那得到更多的反饋來改進(jìn)產(chǎn)品。正因?yàn)榘l(fā)布頻繁，每一個(gè)版本新增的功能簡單，不需要復(fù)雜的設(shè)計(jì)，這樣文檔和設(shè)計(jì)就在很大程度上簡化了。又因?yàn)楹唵卧O(shè)計(jì)，沒有復(fù)雜的架構(gòu)，所以客戶有新的需求或者需求進(jìn)行變動(dòng)，也能很快的適應(yīng)。
Minimal Documentation，較少的文檔
其實(shí)敏捷開發(fā)中并不是沒有文檔，而是有大量的文檔，即測(cè)試。這些測(cè)試代碼真實(shí)的反應(yīng)了客戶的需求以及系統(tǒng)API 的用法，如果有新人加入團(tuán)隊(duì)，最快的熟悉項(xiàng)目的方法就是給他看測(cè)試代碼，而比一邊看著文檔一邊進(jìn)行debug要高效。如果用書面文檔或者注釋，某天代碼變化了，需要對(duì)這些文檔進(jìn)行更新。一旦忘記更新文檔，就會(huì)出現(xiàn)代碼和文檔不匹配的情況，這更加會(huì)讓人迷惑。而在敏捷中并不會(huì)出現(xiàn)，因?yàn)橹挥袦y(cè)試變化了，代碼才會(huì)變化，測(cè)試是真實(shí)反應(yīng)代碼的。這時(shí)有人會(huì)問：代碼不寫注釋行嗎？一般來說好的代碼不是需要大量的注釋嗎？其實(shí)簡單可讀的代碼才是好的代碼，既然簡單可讀了，別人一看就能夠看懂，這時(shí)候根本不需要對(duì)代碼進(jìn)行任何注釋。若你覺得這段代碼不加注釋的話別人可能看不懂，就表示設(shè)計(jì)還不夠簡單，需要對(duì)它進(jìn)行重構(gòu)。
Collaborative Focus，以合作為中心，表現(xiàn)為代碼共享
在敏捷開發(fā)中，代碼是歸團(tuán)隊(duì)所有而不是哪些模塊的代碼屬于哪些人，每個(gè)人都有權(quán)利獲得系統(tǒng)任何一部分的代碼然后修改它，如果有人看到某些代碼不爽的話，那他能夠?qū)@部分代碼重構(gòu)而不需要征求代碼作者的同意，很可能也不知道是誰寫的這部分代碼。這樣每個(gè)人都能熟悉系統(tǒng)的代碼，即使團(tuán)隊(duì)的人員變動(dòng)，也沒有風(fēng)險(xiǎn)。
Customer Engagement ，現(xiàn)場(chǎng)客戶
敏捷開發(fā)中，客戶是與開發(fā)團(tuán)隊(duì)一起工作的，團(tuán)隊(duì)到客戶現(xiàn)場(chǎng)進(jìn)行開發(fā)或者邀請(qǐng)客戶到團(tuán)隊(duì)公司里來開發(fā)。如果開發(fā)過程中有什么問題或者產(chǎn)品經(jīng)過一個(gè)迭代后，能夠以最快速度得到客戶的反饋。
Automated Testing ，自動(dòng)化測(cè)試
為了減小人力或者重復(fù)勞動(dòng)，所有的測(cè)試包括單元測(cè)試、功能測(cè)試或集成測(cè)試等都是自動(dòng)化的，這對(duì)QA人員提出了更高的要求。他們要熟悉開發(fā)語言、自動(dòng)化測(cè)試工具，能夠編寫自動(dòng)化測(cè)試腳本或者用工具錄制。我們公司在自動(dòng)化測(cè)試上做了大量的工作，包括Selenium開源項(xiàng)目。
Adaptive Planning，可調(diào)整計(jì)劃
敏捷開發(fā)中計(jì)劃是可調(diào)整的，并不是像以往的開發(fā)過程中，需求分析->概要設(shè)計(jì)->詳細(xì)設(shè)計(jì)->開發(fā) ->測(cè)試->交付，每一個(gè)階段都是有計(jì)劃的進(jìn)行，一個(gè)階段結(jié)束便開始下一個(gè)階段。而敏捷開發(fā)中只有一次一次的迭代，小版本的發(fā)布，根據(jù)客戶反饋隨時(shí)作出相應(yīng)的調(diào)整和變化。
敏捷開發(fā)過程與傳統(tǒng)的開發(fā)過程有很大不同，在這過程中，團(tuán)隊(duì)是有激情有活力的，能夠適應(yīng)更大的變化，做出更高質(zhì)量的軟件。
開發(fā)流程
開發(fā)溝通工具
敏捷開發(fā)那些被忽視的步驟
測(cè)試驅(qū)動(dòng)開發(fā)
測(cè)試驅(qū)動(dòng)開發(fā)，目前還是非常難以推廣的，因?yàn)槿绻舨捎妹嫦蜻^程開發(fā)系統(tǒng)，那么測(cè)試驅(qū)動(dòng)開發(fā)就難以落地。
重構(gòu)
重構(gòu)不等于重寫，也不等于重新修改，重構(gòu)需要站在整體系統(tǒng)層面做優(yōu)化，為了拓展性和復(fù)用性而優(yōu)化調(diào)整，而不是簡單的對(duì)某個(gè)功能做修改，對(duì)技術(shù)人員的要求比較高，同時(shí)也對(duì)團(tuán)隊(duì)整體的要求比較高。
自動(dòng)化測(cè)試
由于開發(fā)過程中，過度重視交付周期，以及功能開發(fā)，弱化測(cè)試環(huán)節(jié)，導(dǎo)致自動(dòng)化測(cè)試本身就難于推廣，因?yàn)槟_本編寫對(duì)技術(shù)要求有一定的門檻。再就是數(shù)據(jù)與系統(tǒng)高度耦合，導(dǎo)致測(cè)試的數(shù)據(jù)流程不一定能夠覆蓋全面。
總結(jié)
測(cè)試是非常重要環(huán)境，自動(dòng)化測(cè)試是系統(tǒng)質(zhì)量的重要保障手段，自動(dòng)化測(cè)試是為了發(fā)現(xiàn)軟件的質(zhì)量問題，單元測(cè)試則是為了確保業(yè)務(wù)的穩(wěn)定性。
在寫代碼的時(shí)候，一個(gè)功能滿足什么樣的測(cè)試流程后，就能算是開發(fā)完成？
一個(gè)系統(tǒng)開發(fā)完成以后，該如何交互使用操作你開發(fā)的這個(gè)功能呢？
自動(dòng)化測(cè)試相關(guān)的技術(shù)框架
Web測(cè)試：
Selenium：一個(gè)廣泛使用的自動(dòng)化測(cè)試框架，可以用于測(cè)試各種Web應(yīng)用程序。它提供了多種編程語言的接口，如Java、C#、Python、Ruby等。
Cypress：一個(gè)用于Web應(yīng)用程序的端到端測(cè)試框架，它旨在使測(cè)試更加快速、簡單和可靠。
移動(dòng)應(yīng)用測(cè)試：
Appium：一款開源工具，用于自動(dòng)化各種平臺(tái)（如iOS、Android和Windows）的移動(dòng)應(yīng)用測(cè)試。
Espresso (Android) / XCTest (iOS)：這兩個(gè)都是各自平臺(tái)原生支持的自動(dòng)化測(cè)試框架。
API測(cè)試：
Postman：非常流行的API測(cè)試工具，可以進(jìn)行自動(dòng)化和手動(dòng)測(cè)試。
Rest-Assured：用于Java的REST服務(wù)測(cè)試的DSL。
性能測(cè)試：
JMeter：開源的負(fù)載和性能測(cè)試工具，可以用于分析和測(cè)量各種服務(wù)的性能。
Gatling：另一個(gè)強(qiáng)大的負(fù)載測(cè)試工具，以Scala編寫，但也可以用于Java項(xiàng)目。
單元測(cè)試：
JUnit（Java）、PyTest（Python）、Mocha/Chai（JavaScript）等，這些都是各自語言的主流單元測(cè)試框架。
持續(xù)集成/持續(xù)部署（CI/CD）：
Jenkins：一個(gè)開源的自動(dòng)化服務(wù)器，可以用來自動(dòng)化各種任務(wù)，包括構(gòu)建、測(cè)試和部署軟件。
GitLab CI/CD：GitLab提供了一個(gè)強(qiáng)大的、內(nèi)置的持續(xù)集成服務(wù)。
