《敏捷軟體開發：原則、模式與實踐》筆記

• 2019 年 12 月 23 日
• 筆記

第一章：敏捷實踐

敏捷開發要點節選：

• 結對編程
• 集體程式碼所有權：所有人可以在任何時候改進所有程式碼
• 隱喻：團隊提出一個程式工作原理的公共景象

如果把程式設計師團隊當做是組件（component），那麼就無法對他們進行管理。人不是「插入即兼容的編程裝置」。如果想要項目取得成功，就必須構建具有合作精神的，自組織的（self-organizing）的團隊。

一個大而笨重的過程會產生它本來企圖去解決的問題。它降低了團隊的開發效率，使得進度延期，預算超支。它降低了團隊的相應能力，使得團隊經常創建錯誤的產品。

程式碼是唯一沒有二義性的資訊源。

計劃會遭受形態（shape）上的改變，而不僅僅是日期上的改變。所以預先制定好的詳細的計劃圖是不適用的。正確做法是：為下兩周做詳細計劃，為下三個月做粗略的計劃，再以後做極為粗糙的計劃。

跑得過快會導致團隊經理好景，出現短期行為一直與崩潰。敏捷團隊會測量他們自己的速度。他們不允許自己過於疲憊。他們不會借用明天的經理賴在今天多完成一點工作。他們工作在一個可以使在整個項目開發期間保持最高品質標準的速度上。

敏捷團隊會不斷地對團隊的組織方式，規則，規範，關係等進行調整。敏捷團隊知道團隊所處的環境在不斷地變化，並且知道為了保持團隊的敏捷性，就必須隨環境一起變化。

第二章：極限（eXtreme Programming）編程概述

在離真正實現需求還很早時就去補貨該需求的特定細節，很可能會導致做無用功以及對需求不成熟的關注。在XP中，我們和客戶反覆討論，以獲取對需求細節的理解，但是不去捕獲那些細節。

測試驅動的開發方法：編寫所有產品程式碼的目的都是為了使失敗的單元測試能夠通過。

簡單的設計：XP 團隊使他們的設計儘可能地簡單，具有表現力（expressive）。這意味著 XP 團隊的工作可能不會從基礎結構開始，他們可能並不先去選擇使用資料庫或者中間件。團隊最開始的工作是以儘可能最簡單的方式實現第一批用戶素材。

因為添加特性和處理錯誤導致程式碼結構逐漸退化，XP 團隊通過經常性的程式碼重構來扭轉這種退化。重構是持續進行的，是每個一個小時或者半個小時就要去做的事情。通過重構，我們可以持續低保持儘可能乾淨，簡單並且具有表現力的程式碼。

第三章：計劃

所有大的用戶素材（user stories）都應該被分解為小的素材，過小的素材應該和其他過小素材合併。

「用戶能夠安全的進行存款，取款，轉賬活動。」可以被分解為：

• 用戶可以登錄
• 用戶可以退出
• 用戶可以向其賬戶存款
• 用戶可以從其賬戶取款
• 用戶可以從其賬戶向其他賬戶轉賬

團隊的開發速度在實現數個素材後可以估算出來，確定素材和開發速度後就可以估算開發時間。

客戶挑選在某個發布中他們想要實現的素材，並大致確定這些素材的實現順序。

分配的任務應該是 4~16 小時內實現的一些功能，多個任務組成一個素材。

迭代進行到一半的時候，此時半數素材應該被完成，如果沒有完成，團隊會設法重新法分配任務和職責。如果不能重新分派，則由客戶決定從迭代中去掉一個任務或素材，或指出哪些最低優先順序別的任務和素材。

如果完成了 90% 任務，但卻沒有完成素材，這是沒有意義的。

迭代結束後，應該給客戶演示當前可運行的程式，讓客戶評價並以新的用戶素材進行回饋。

第四章：測試

測試驅動開發使你的程式碼都是對測試友好的。

測試可以作為一種無價的文檔形式，如果想知道如何調用一個函數或者創建一個對象，會有一個測試戰士給你看。

在實現錢，現在測試中陳述你的意圖，使你的意圖儘可能地簡單，已讀，你相信這種簡單和清除會給程式指出一個好的結構。

MockObject 用於配合目標類的功能測試，相對比真實實現類好更好控制一些。

單元測試是白盒測試，驗收測試是黑盒測試。

在項目迭代的初期，會受到用手工的方式進行驗收測試的誘惑。但是，這樣做使得在迭代的初期就喪失了由自動化驗收測試的需要帶來的對系統進行解耦合的促進力。

測試套件運行起來越簡單，就會越頻繁地運行它們。運行的越多，就會越快地發現和那些測試的任何背離。

第五章：重構

每一個軟體都具有三項職責：

• 運行起來所完成的功能
• 應對變化，開發者有責任保證這種改變應該儘可能簡單
• 和閱讀它的人溝通

程式碼應能夠清晰的表述各個子流程的意義，最常用的方法是將其封裝為一個函數。

版權所有，轉載請註明出處： https://sickworm.com/?p=1678