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

標籤：工作量   改善   http   ima   高品質   設計方案   崗位   層級   bsp   

 

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

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

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

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

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

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

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

 

 

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

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

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

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

 

 

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

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