架構雜談《十》

架構雜談《十》

常用開發模式

一、瀑布式開發

　　瀑布式開發是在1970年提出的軟體開發模型，是一種較老的電腦軟體開發模式，也是典型的預見性的開發模式，在瀑布式開發中，開發嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟進行，步驟的成果作為衡量進度的方法。瀑布式開發最早強調系統開發應有完整的周期，且必須完成完整地經歷每個周期內的每個階段，並系統化地考量分析所設計的技術、時間與資源等。

　　瀑布式開發的主要問題是它嚴格分級導致自由度降低，在需求不明確並且在項目進行過程中可能有變化的情況下基本上是不可行的。

（瀑布式開發模式圖）

二、迭代式開發

　　迭代式開發也稱迭代增量式開發，是一種與瀑布式開發相反的軟體開發過程，它彌補了瀑布式開發方式的一些弱點，有更高的成功率。在迭代式開發中，整個開發工作被組織成一系列短小的、固定長度的小項目，每次迭代都包括需求分析、設計、實現與測試。採用迭代式開發時，工作可以在需求被確定之前啟動，併在一次迭代中完成系統的一部分功能或業務，再通過客戶的反饋來細化需求，並開始新一輪的迭代。

（迭代式開發模式圖）

　　迭代式開發有以下的特點：

　　　　1）每次只設計和實現產品的一部分

　　　　2）一步一步地完成

　　　　3）每次設計和實現一個階段，這叫作迭代

三、螺旋式開發

　　螺旋式開發兼顧了快速原型的迭代特征及瀑布模型的系統化和嚴格監控，其最大的特點是引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減少損失。同時，在每個迭代階段構建原型是螺旋模型用來減少風險的方法。螺旋模型更適合大型的高昂的系統級的軟體開發，一開始應用的規模很小，當項目被定義得更好、更穩定時逐漸展開。其核心在於不需要在剛開始時就把所有的事情都定義清楚，可以先定義最重要的功能去實現，然後聽取客戶的意見再進行下一個階段，如此不斷迴圈、重覆，直到得到滿意的產品。螺旋模型在很大程度上是一種風險驅動的方法體系，因為在每個階段及經常發生的迴圈之前，都必須先進行風險評估。

（螺旋模型圖）

　　螺旋模型具有如下的特點：

　　　　1）制定計劃：確定軟體目標，選定實施方案，搞清楚項目開發的限制條件

　　　　2）風險分析：分析、評估所選方案，考慮如何識別和消除風險

　　　　3）實施工程：實施軟體開發和驗證

　　　　4）客戶評估：評價開發工作，提出修正意見。制定下一步計劃

四、敏捷軟體開發

　　敏捷軟體開發又成敏捷開發，是一種從1990年開始逐漸引起人們廣泛關註的新型軟體開發方式，具有應對快速變化的需求的軟體開發能力，相對於非敏捷開發，更強調程式員團隊與業務專家之間的緊密協作及面對面溝通，比單純通過書面文檔溝通更有效，能更頻繁地交付新的軟體版本，使自我組織、自我約束的團隊能夠更好地適應需求的變化，也更關註軟體開發過程中人的作用。

　　敏捷軟體開發有如下特點：

　　　　1）首要任務是儘早地、持續地交付可評價的軟體，使得客戶滿意

　　　　2）樂於接受需求變更，即使在開發後期也是如此，敏捷軟體開發能夠駕馭需求的變化，從而為客戶贏得競爭優勢

　　　　3）頻繁交付可使用的軟體，交付的間隔越短越好，可以從幾個月縮減到幾個星期

　　　　4）在整個項目開發期間，業務人員和開發人員必須朝夕工作在一起

　　　　5）圍繞那些有推動力的人們來構建項目。給予他們所需的環境和支持，並且相信他們能夠把工作做好

　　　　6）可使用的軟體是進度的主要衡量指標

　　　　7）提倡可持續發展

　　　　8）為了增強敏捷能力，應持續關註技術上的傑出成果和良好的設計

　　　　9）簡潔，最小化那些沒有必要投入的工作量是至關重要的

　　　　10）最好的架構、需求和設計都源於自我組織的團隊

 　　對比以上4種開發模式，總結如下：

　　　　1）瀑布式開發：在從需求到設計、從設計到編碼、從編碼到測試、從測試到提交的每個開發階段都要做到最好，特別是在前期階段設計得越完美，提交後的損失就越少。然而現在的系統很複雜且多變，所以很難在現實中應用瀑布式開發。

　　　　2）迭代式開發：不要求每個階段的任務都做到最好，可以容忍一些不足，先不去完善它，將主要功能先搭建起來，以最短的時間及最少的損失完成一個不完美的成果直至提交，然後通過客戶或用戶的反饋，在這個不完美的成果上逐步進行完善。

　　　　3）螺旋開發：在很大程度上是一種風險驅動的方法體系，因為在每個階段及經常發生的循環之前，都必須先進行風險評估。

　　　　4）敏捷開發：和迭代式開發相比，兩者都強調在較短的開發周期內提交軟體，但是敏捷開發的周期可能更短且更強調隊伍中的高度協作。敏捷方法有時被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性，適應性的方法主要用於快速適應需求的變化。當項目的需求有變化時，團隊能夠迅速應對新的需求 。 

　　在一般公司里，採用敏捷開發和不斷迭代開發的方式較多，而且效率高、效果明顯。因為之前做的系統業務單一、邏輯簡單、用戶量少，項目團隊的規模一般在10-30人，現在的系統要面對不同用戶的定製化開發，業務變得越來越複雜，功能越來越多，如果整個系統耦合在一起，必定會牽一發而動全身，導致系統維護困難，同時每個公司面臨著人員的頻繁流動、系統文檔不完善或多次轉手丟失等情況，以至於新來的人員很難快速上手。因而，人們開始思考如何高效地解決複雜的大型系統開發模式。

說明：

　　1、參考書籍：《分散式服務架構：原理、設計與實戰》《微服務架構與實踐》

　　2、如有不合適的地方請反饋。綜合後更改。

　　3、文中圖片來源於百度圖片