敏捷開發

1、敏捷開發

一、概念，能夠參考敏捷宣言，強調適應變化，四句指導

個體和互動 高於 流程和工具（動員每一個人積極交流，相互之間能夠 battle，頭腦風暴）；

工做的軟件 高於 詳盡的文檔（好的代碼是不須要註釋和文檔的，頂多有一些規範指南一類的在線協做文檔）；

客戶合做 高於 合同談判（真心實意爲客戶創造價值，而不止於眼前的功能交付，這個很難，由此還專門有一個角色去 control 這件事）；

響應變化 高於 遵循計劃（計劃是趕不上變化的，隨時改需求隨時變更迭代計劃，有迭代的概念）；

基於於右邊，而更注重左邊的價值，並非說徹底拋棄傳統的瀑布式開發。

二、人員架構

由於公司沒有所謂的各類領導，這裏就說下交付組裏，我所見的一些角色，也是天天在一塊兒工做的小夥伴：

PM：項目管理者，這裏不是項目經理，負責和客戶籤合同，各類會議的組織者，沒有項目經理那種權利 BA：業務分析師，專門和客戶談需求，超強的交流和控制客戶的能力，幾乎天天都和客戶泡在一塊兒開會過需求，瘋狂開會，驅動客戶（咱們組的BA是御姐型的，氣場極強） QA：測試人員 DEV：開發人員，其中有掌握技術話語權的 TL

PO：比較特殊，是客戶某的部門領導人，通常和 PM 單獨溝通，幾乎沒出現過，網友同樣的存在

一個團隊通常 1 PM、1 BA、1 QA 、6 DEV (三前三後，至少兩個TL)

三、會議

IPM：迭代會議，每一個迭代開始以前開一次，主要是排下個迭代的故事卡（任務卡），並給每張卡估點，我遇到的是兩週一個迭代（通常會有卡牆，有物理的，也有線上的）

Showcase：開發成果展現，每一個迭代結束開一次，通常是BA或QA給客戶演示上個迭代作的功能，固然也是優化和新改動提得最多的時候

Retro：回顧會議，每一個迭代結束開一次，討論上個迭代團隊作得好和作得很差的事（不是針對和人，不含人身攻擊），並給出改進方案，在下個迭代中執行

Stand Up：天天早上的站會，你們站成一圈，通常由 PM 主持，輪流闡述本身的昨天工做內容和工做進度，和今天要完成的工做，以及遇到的一些問題，及時反饋出來（咱們組有個小龍貓的毛絨玩具，你們挨個傳遞，挨個闡述）

天天還有 Code Review，動態安排時間，咱們團隊一直堅持，剛開始是先後端一塊兒過昨天每一個人寫的代碼，後面時間太長，就先後端分開。你們一塊兒來找茬，你的命名和代碼邏輯劃分，代碼風格，都有個能會被挑刺。在相互找茬的過程當中，堅持下去，對我的的成長有很大很大的幫助。

四、寫代碼

DEV 要作開發，就要先領故事卡，俗稱開卡，本身選好一張故事卡，拉上BA和QA去過其中的細節，理清細節，而後才能上手開發，開發完後再拉上BA和QA去結卡，檢查卡中的功能是否是都完成了，有問題就被打回去改，直到BA和QA以爲完善了，才能關卡。。。

代碼質量要求很嚴格，遵循 TDD，前端有lint，有單元測試（不能偷懶，並且有覆蓋率要求），有 e2e 測試（必須寫，和QA一塊兒看），當你的代碼走過這三個流程，提交到公共倉庫，CI 自動構建會拉你的代碼，再走一遍測試（掛了就要修代碼），而後自動發佈新版本到 Dev 環境。

你覺得這就完了？還有代碼嗅探器，時刻在掃描代碼倉庫，有兩個重複的函數不行、重複率過高不行、使用了騷代碼去作類型轉換之類的不行、空間內有命名重疊不行。。。。這一套下來，再加上 codereview，菜鳥開發天天一半的時間都在改昨天的代碼。

項目還有規定，CI 不能紅過夜，當天的問題當天要修好。。。。

2、TDD（測試驅動開發）

1.TDD是什麼

TDD 是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼以前，先編寫單元測試用例代碼，測試代碼，肯定須要編寫什麼產品代碼。保證軟件開發中的質量

2.TDD 有三層含義：

Test-Driven Development，測試驅動開發。

Task-Driven Development，任務驅動開發，要對問題進行分析並進行任務分解。

Test-Driven Design，測試保護下的設計改善。TDD 並不能直接提升設計能力，它只是給你更多機會和保障去改善設計。

3.爲何TDD

簡單設計

提早澄清需求：先寫測試能夠幫助咱們去思考需求，並提早澄清需求細節，而不是代碼寫到一半才發現不明確的需求。

快速反饋：快速反饋是單元測試的好處。debug free

安全網：TDD 的好處是覆蓋徹底的單元測試，對產品代碼提供了一個保護網，讓咱們能夠輕鬆地迎接需求

TDD流程

1.先分解任務，分離關注點,把一個大需求拆成多個小需求, 也能夠拆出多個函數來

2.列 Example，用實例化需求，澄清需求細節

3.寫測試，只關注需求，程序的輸入輸出，不關心中間過程

另外：好的單元測試應該符合幾條原則：

簡單，只測試一個需求

符合 Given-When-Then 格式

速度快

包含斷言

能夠重複執行 先寫測試再寫需求

4.寫實現，不考慮別的需求，用最簡單的方式知足當前這個小需求便可 重構，用手法消除代碼裏的壞味道

5.寫完，手動測試一下，基本沒什麼問題，有問題補個用例，修復 轉測試，小問題，補用例，修復（測試經過後可進行重構，優化代碼）

6.代碼整潔且用例齊全，信心滿滿地提交

TDD 的三條規則

1.除非是爲了使一個失敗的單元測試經過，不然不容許編寫任何產品代碼

2.在一個單元測試中，只容許編寫恰好可以致使失敗的內容（編譯錯誤也算失敗）

3.只容許編寫恰好可以使一個失敗的 unit test 經過的產品代碼

若是違反了會怎麼樣呢？

1.違反第一條，先編寫了產品代碼，那這段代碼是爲了實現什麼需求呢？怎麼確保它真的實現了呢？

2.違反第二條，寫了多個失敗的測試，若是測試長時間不能經過，會增長開發者的壓力，另外，測試可能會被重構，這時會增長測試的修改爲本。

3.違反第三條，產品代碼實現了超出當前測試的功能，那麼這部分代碼就沒有測試的保護，不知道是否正確，須要手工測試。可能這是不存在的需求，那就憑空增長了代碼的複雜性。若是是存在的需求，那後面的測試寫出來就會直接經過，破壞了 TDD 的節奏感。

本質是： 分離關注點，一次只戴一頂帽子

在咱們編程的過程當中，有幾個關注點：需求，實現，設計。

TDD 給了咱們明確的三個步驟，每一個步驟關注一個方面。

紅：寫一個失敗的測試，它是對一個小需求的描述，只須要關心輸入輸出，這個時候根本不用關心如何實現。

綠：專一在用最快的方式實現當前這個小需求，不用關心其餘需求，也不要管代碼的質量多麼慘不忍睹。

重構：既不用思考需求，也沒有實現的壓力，只須要找出代碼中的壞味道，並用一個手法消除它，讓代碼變成整潔的代碼。

注意力控制： 使用 TDD 開發，咱們要主動去控制注意力，寫測試的時候，發現一個類沒有定義，IDE 提示編譯錯誤，這時候你若是去建立這個類，你的注意力就不在需求上了，已經切換到了實現上，咱們應該專一地寫完這個測試，思考它是否表達了需求，肯定無誤後再開始去消除編譯錯誤。

實戰操做技巧

1.選一個最簡單的用例，直接開寫，用最簡單的代碼經過測試。逐漸增長測試，讓代碼變複雜，用重構來驅動出設計。

2.維護時也遵循 TDD 流程，先修改測試代碼成需求變動後的樣子，讓測試失敗，再修改產品代碼使其經過。這樣你就不是在維護測試用例，而是在利用測試用例。

好比word-frequency-tdd-demo的例子，計算文件中單詞的頻率

①首先想一下大概的流程，要作什麼

（主要是爲了任務拆分）

②列輸入輸出的example

大概能夠想到以下的用例：

"" => ""  爲空的狀況
"he" => "he 1"，一個單詞，驅動出格式化字符串的代碼
"he is" => "he 1\r\nis 1"，兩個不一樣單詞，驅動出分割單詞的代碼
"he he is" => "he 2\r\nis 1"，有相同單詞，驅動出分組代碼
"he is is" => "is 2\r\nhe 1"，驅動出分組後的排序代碼
"he is" => "he 1\r\nis 1"，多個空格，完善分割單詞的代碼
複製代碼