前言
最近想學習敏捷開發，在看一本書，叫《敏捷技能修煉-敏捷軟件開發與設計的最佳實踐》。正如書中所說，兩個同等經驗的程序員，在效率和質量上可能會有10倍的差距。隨着寫的代碼越來越多，我也有這種體會，我們寫的代碼不能只是功能的實現，還應該注重代碼的質量，如可讀性、易理解、易修改等。
書中第一部分介紹了”小舵板”理論，分別是：
- 意圖導向編程
- 分離構造和使用
- 代碼未動，測試先行
意圖導向編程
意圖導向編程也稱目的導向編程，在使用意圖導向編程時，我們把一個問題分解爲一系列功能性步驟，並假定這些功能步驟已經實現，我們只需把把各個函數組織在一起即可解決這一問題。在組織好整個功能後，我們在分別實現各個方法函數。舉書中的一個例子，假設我們需要創建一個交易業務的服務程序，具體需求如下：
- 交易信息開始於一串標準ASCII字符串。
- 這個信息字符串必須轉換成一個字符串的數組，數組存放的此次交易的領域語言中所包含的詞彙元素（token)。
- 每一個詞彙必須標準化。
- 包含超過150個詞彙元素的交易，應該採用不同於小型交易的方式（不同的算法）來提交，以提高效率。
- 如果提交成功，API返回”true”；失敗，則返回”false”。
這裏沒有涉及具體細節，並假定具體算法已實現。
需求中的每一點都代表一個功能性步驟，使用意圖導向編程，我們假定每一個功能步驟已經實現，我們可以寫出下面的代碼
public class Transaction
{
public Boolean commit(String command)
{
Boolean result = true;
String[] tokens = tokenize(command);
normalizeTokens(tokens);
if (isALargeTransaction(tokens))
{
result = processLargeTransaction(tokens);
}
else
{
result = processSmallTransaction(tokens);
}
return result;
}
}
commit()方法是我們定義的應用程序接口（API），它是公用方法，該方法只是一系列的方法調用，實現一系列意圖。
接下來，我們就可以分別實現各個方法，如果是團隊開發，還可根據團隊中的特點分配任務。
使用意圖導向編程的優點
如果遵循意圖導向編程的方式，那麼代碼將會：
- 更加內聚（職責單一）。
- 更加可讀和清晰。
- 更易於調試。
- 更易於重構和優化，所以只做最少的設計，滿足當前需求。
- 更易於單元測試。
同時，從這些優點中還會延伸出其他優點：代碼更易於修改個擴展。其他還有：
- 模式更易應用到代碼。
- 創建的方法可以容易地從一個類移動到另一個類。
- 代碼更易於維護。
更重要的是，遵循意圖導向編程的方式並不用花費額外的精力。
關於代碼註釋
關於代碼註釋衆說紛紜，《代碼大全》一書中主張代碼要有自說明性，因爲代碼纔是最新的，而註釋可能已經過時（修改代碼但是未修改註釋），我比較贊同這個觀點。意圖編程就帶來了一個額外的好處，代碼基本上就是自說明的，看看上面這段代碼，幾乎不用再註釋它了，代碼本身就充當了註釋的作用。
結語
以上就是關於意圖導向編程的介紹，後續還會繼續把其他”小舵板”更新。