《敏捷式軟體開發 (Agile Software Development)》讀書筆記

1、 
敏捷式軟體開發 (Agile Software Development)宣言

我們正在通過親身實踐以及協助他人實踐，揭示更好的軟體開發方法。通過這項工作，我們認為：

個體和互動            勝過       過程和工程。

可以工作的軟體      勝過       面面俱到的文檔。

客戶合作               勝過       合約談判。

響應變化               勝過       遵循計劃。

雖然右項也具有價值，但我們認為左項具有更大的價值。

 

2、 
敏捷宣言遵循的原則

我們遵循一下原則：

l        
我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。

l        
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

l        
經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

l        
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

l        
圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支援，並且信任他們能夠完成工作。

l        
在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。

l        
工作的軟體是首要的進度度量標準。

l        
敏捷過程提倡可持續的開發速度。責任人、開發人員和使用者應該能夠保持一個長期的、恒定的開發速度。

l        
不斷地關注優秀的技能和好的設計會增強敏捷能力。

l        
簡單——使未完成的工作最大化的藝術——是根本的。

l        
最好的架構、需求和設計出自於自組織的團隊。

l        
每個一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

 

3、 
物件導向設計的原則

3.1      
SRP —— 單一職責原則，Single Responsibility Principle

就一個類而言，應該僅有一個引起它變化的原因。

 

3.2      
OCP —— 開放 - 封閉原則，Open –
Close Principle

軟體實體（類、模組、函數等）應該是可以擴充的，但是不可修改。

 

3.3      
LSP —— Liskov替換原則，Liskov Substitution Principle

子類型必須能夠替換掉它們的基底類型。

 

3.4      
DIP —— 依賴倒置原則，Dependence Inversion Principle

抽象不應該依賴於細節。細節應該依賴於抽象。

 

3.5      
ISP —— 介面隔離原則，Interface Separate Principle

不應該強迫客戶依賴於它們不用的方法。

介面屬於客戶，不屬於它所在的類階層。

 

3.6      
REP —— 重用發布等價原則

重用的粒度就是發布的粒度。

 

3.7      
CCP —— 共同封閉原則

包中的所有類對於同一個類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，這將對該包中的所有類產生影響，而對於其他的包不造成任何影響。

 

3.8      
CRP —— 共同重用原則

一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。

 

3.9      
ADP —— 無環依賴原則

在包的依賴關係圖中不允許存在環。

 

3.10   
SDP —— 穩定依賴原則

朝著穩定的方向進行依賴。

 

3.11   
SAP —— 穩定抽象原則

包的抽象程度應該和其穩定程度一致。

 

4、 
極限編程實踐

4.1    
完整團隊

XP項目的所有參與者（開發人員、商務分析師、測試人員等等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的顯著的圖表以及其他一些顯示他們進度的東西。

 

4.2    
計劃遊戲

計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

 

4.3    
客戶測試

作為選擇每個所期望的特性的一部分，客戶定義出自動驗收測試來表明該特性可以工作。

 

4.4    
簡單設計

團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含儘可能少的代碼。

 

4.5    
結對程式設計

所有的產品軟體都是由兩個程式員、並排坐在一起在同一台機器上構建的。

 

4.6    
測試驅動開發

程式員以非常短的重複持續時間工作，他們先增加一個失敗的測試，以後使之通過。

 

4.7    
改進設計

隨時改進糟糕的代碼。保持代碼儘可能的乾淨、具有表達力。

 

4.8    
持續整合

團隊總是使系統完整地被整合。

 

4.9    
集體代碼所有權

任何結對的程式員都可以在任務時候改進任何代碼。

 

4.10 
編碼通訊協定

系統中所有的代碼看起來就好像是被單獨一個
—— 非常值得勝任的 —— 人編寫的。

 

4.11 
隱喻

團隊提出一個程式工作原理的公用景象。

 

4.12 
可持續的速度

團隊只有持久才有擷取的希望。他們以能夠長期維持的速度努力工作。他們儲存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。