建議154：不要過度設計，在敏捷中體會重構的樂趣

有時候，我們不得不隨時更改軟件的設計：

• 如果項目是針對某個大型機構的，不同級別的軟件使用者，會提出不同的需求，或者隨著關鍵崗位人員的更替，需求也會隨個人意誌有所變更。
• 如果競爭對手增加了新需求，我們也不得不為正在研發的新產品調整設計方案。
• 剛開始的架構太糟糕了，這可能源於設計經驗的不足或者架構師的不負責任。

以上分別從外部和內部描述了必須修改需求和設計的幾種場景。也就是說，在軟件開發過程中，變化幾乎總會發生。

為了捕捉需求上的不斷變化，軟件開發必須變得足夠“敏捷”。設計也應該停留在“高層次”上，具有指導作用，而功能模塊（或者說代碼）則需要逐步改進。我們把改進的過程稱為“重構”.

傳統的瀑布開發由於不能滿足需求的變化，在軟件領域被各類敏捷開發框架所取代。

敏捷開發模式把整個開發過程分成了一個一個的叠代，每個叠代的周期大概是兩周到一個月。每個叠代大致分為如下幾個步驟。

敏捷開發使用“用戶故事”（User Story，在TFS敏捷規範中，它被歸類到BackLog）來核定需求和工作量指標。在一個叠代開始的時候，開發團隊應該挑選用戶故事作為本次叠代的目標；而在每一次叠代結束的時候，用戶故事應該開發完畢。整個開發部門必須發布一個可以運行的版本交付給客戶（對象可以是真實的用戶，也可以是團隊運營部門）。這有助於客戶及時調整他們對產品的預期，並修正可能存在的需求變動。而作為開發團隊，也可以根據客戶的反饋修正需求，甚至是設計。

正是因為敏捷開發擁抱變化，所以站在整個開發流程來看，設計應該是可以修改的，而落實到代碼上來，也就是重構的地位提升了。在敏捷開發體系中，我們可以將其作為一個任務（Task）引入整個開發流程中。

作為一個團隊，需要定期審視模塊是否可以被重構。而作為開發人員，建議一旦嗅到代碼的壞味道，就需要重構我們的代碼。

我們不追求讓代碼第一個版本就保持非常整潔的程度，那不現實，而且會讓開發者覺得無從下手。當然，我們更不應該讓繁雜的代碼永遠保持在第一個版本的狀態，那樣的代碼，讓我自己都不滿意。

轉自：《編寫高質量代碼改善C#程序的157個建議》陸敏技

【轉】編寫高質量代碼改善C#程序的157個建議——建議154：不要過度設計，在敏捷中體會重構的樂趣