【轉】 代碼設計敏捷開發三部曲

【轉】 代碼設計敏捷開發三部曲

1、敏捷開發與MVP

1.mvp

Eric Ries曾在《精益創業實戰》中提出MVP（minimum viable product）概念，意即「最簡可行產品」——用最快、最簡明的方式創建一個可用的產品原型，這個原型要表達出你產品最終想要的效果，而後經過迭代來完善細節

從如今敏捷開發的角度來說，這是快速迭代產品的最最好方式之一就是mvp，不求大而全。

2.敏捷開發三部曲：《設計模式》-> 《重構》-> 《重構與模式》。也就是設計->重構->重構出新設計。

《設計模式》主要詳細說明20幾種模式，爲咱們帶來了常見設計問題的經典解決方案，從而改變了整個面向對象開發的面貌。爲設計而著。

《重構》改善既有代碼的設計，總結了咱們會用到的各類重構手法，爲咱們帶來了一種改進代碼的高效過程，從而完全改變了面向對象設計的方式。側重去除壞代碼的味道。

《重構與模式》是設計模式相關的重構。模式不是設計出來的，是重構出來的。好的設計也不是設計出來的，是重構出來的。不要怕改變，只要改變得法，變就再也不是災難，而是進步的良機。側重設計模式+重構手段。

在閱讀重構與模式以前，最好熟讀前面兩本：《設計模式》和《重構》。

設計模式表明了傳統的軟件開發思想：好的設計會產生好的軟件，所以在實際開發以前，值得花時間去作一個全面而細緻的設計。重構表明了敏捷軟件開發的浪潮：軟件並非在一開始就能夠設計得天衣無縫的，所以能夠先進行實際開發，而後經過對代碼不斷的進行小幅度的修改來改善其設計。兩者從不一樣角度闡述了設計的重要性。

有些人在編寫任何代碼以前，都要很早地爲模式作計劃，而有些人在編寫了大量代碼以後纔開始添加模式。

第二種使用模式的方式就是重構，由於是要在不增長系統特性或者不改變其外部行爲的狀況下改變系統的設計。

有些人在程序中加入模式，只是由於以爲模式可以使程序更容易修改；更多人這樣作只是爲了簡化目前的設計。

若是代碼已經編寫，這兩種情形都是重構，由於前者是經過重構使修改更容易，然後者則是經過重構在修改後進行整理。

雖然模式是在程序中可以看到的東西，可是模式也是一種程序轉換。

重構是實現設計模式的一種手段，設計模式每每也是重構的目的。

2、重構與模式的原因

應該經過重構實現模式、趨向模式和去除模式(refactoring to, towards, and away from pattern)，而不是在預先設計中使用模式，也再也不過早的在代碼中加入模式。這技能避免過分設計，又不至於設計不足。

1.過分設計

代碼的靈活性和複雜性超出所需。有些開始設計的時候，認爲某些地方會頻繁的改動，甚至開始使用了某種設計模式預留擴展，可是後來卻沒怎麼動，也就是致使了廢設計和功能.。

2.設計不足

產生設計不足的緣由：

1）程序員沒有時間，沒有抽出時間，或者時間不容許進行重構

2）程序員在何爲好的軟件設計方面知識不足

3）程序員被要求在既有系統中快速的添加新功能

4）程序員被迫同時進行太多項目

長期的設計不足，會使軟件開發節奏變成「快，慢，更慢」，可能的後果是：

1.0版本很快就交付了，可是代碼質量不好

2.0版本也交付了，但質量低劣的代碼使咱們慢下來

在企圖交付將來版本時，隨着劣質代碼的倍增，開發速度也愈來愈慢，最後人們對系統、程序員乃至使你們陷入這種境地的整個過程都失去了信心

到了4.0版本時或者以後，咱們意識到這樣確定不行，開始考慮推倒重來。

3.測試驅動開發和持續重構

測試驅動開發和持續重構提供了一種精益、迭代和訓練有素的編程風格，可以最大程度的有張有弛，提升生產率。「迅速而又從容不迫」

使用測試驅動開發和持續重構的益處：

1）保持較低的缺陷數量

2）大膽的進行重構

3）獲得更加簡單、更加優秀的代碼

4）編程時沒有壓力

模式和重構之間存在着自然聯繫，模式是你想達到的目的地，而重構則是從其餘地方抵達這個目的地的條條道路。

4.演進式設計

演進式設計即趨向性設計，主要是避免過分設計。

經過重構產生設計結構，也就是經過重構實現模式或者重構趨向模式。爲設計而設計的思路並不適合大項目，按部就班從重構到設計模式纔是設計模式的王道。

敏捷開發中常常採用的演進式架構設計：

不少程序員可能都碰見過這種事：某塊代碼亟待修改，卻沒有人願意接手。爲何會這樣？這段代碼正巧是兩個組件間的接口，修改工做太過困難。而在演進式設計中，咱們經常會作這種修改。代碼應當是"活的"而且是"可生長"的，決不能無視強烈的變化需求 而保持一成不變。正由於如此，演進式設計能夠提升設計質量，進而提升整個系統的質量。

 

 

 

本文轉自：一點資訊

微信號：IdeaofSE