目錄
-
前言
作爲一名程序員，我們特別擅長用編程語言實現一個個系統功能。但是我們非常頭疼產品同學一次次提出的需求變更。因爲需求變更會導致程序員對已有代碼進行改造，如果是自己的代碼還稍微好一些，要是改他人的代碼，估計心中一定有無數奔騰的草泥馬。爲什麼維護老代碼會這麼的痛苦呢？當我們面對一堆陌生而複雜的代碼時往往不知所措，看不懂代碼思路，不知道業務邏輯，不知道修改後會不會影響其他邏輯。所以程序員喜歡做新項目和新功能，不願意維護老系統和他人的代碼。
怎麼才能讓維護老代碼不成爲又一個程序員噩夢呢？最理想的辦法就是需求確認後就永遠不要發生變化，這種情況肯定是不可能的。我們只能讓代碼更加優秀，在面對需求變化的時候，維護起來很容易。所以人們發明了許多理論來解決這個問題。
首先是開發模型從傳統的瀑布模型轉變爲敏捷開發模型；
其次編程思想從面向過程編程轉變爲面向對象編程；
最後優秀的代碼都是重構出來的，人們總結出了重構原則和設計模式。
-
軟件開發模型
軟件開發模型是從傳統建築工程借鑑來的，就是瀑布模型，大概的過程是需求分析、產品設計、系統設計、系統研發、系統測試、系統發佈。最初瀑布模型很好的滿足了需求，但是後來它就導致了很多軟件項目的失敗。失敗的原因很多，比較典型的就是開發週期過長導致軟件已經過時無法滿足新需求。
爲了縮短開發週期和應對需求變化，人們提出了敏捷開發理論，大概思想是簡化初始需求，快速迭代演化，降低試錯成本。需求和市場是不斷變化的，軟件產品不斷快速升級來應對變化。目前來看敏捷開發模型符合實際研發需求。迭代與迭代之間的空隙給重構代碼提供了機會，可以讓代碼不斷優化。
敏捷開發
敏捷開發的迭代對象是故事。將一個大故事拆分成多個小故事，然後分成多次迭代週期進行實現。
故事三要素：
1.角色：誰要使用這個功能。
2.功能：需要完成什麼樣的功能。
3.價值：爲什麼需要這個功能，這個功能帶來什麼樣的價值。
故事表達格式：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作爲一個<角色>, 我想要<功能>, 以便於<商業價值>
舉例：“作爲招聘網站註冊用戶，我想要查看最近3天發佈的招聘信息，以便於我看到最新的招聘信息”。
理想的用戶故事是這樣子的：
企業可以發佈商品。
用戶可以搜索商品。
用戶可以使用信用卡付款。
-
面向對象編程思想
敏捷開發模型從項目開發過程提出瞭解決方案，但是編程思想也出現了問題。人們一直以來都是以計算機的思維在編寫程序，就是所謂的面向過程編程思想。這導致程序代碼讓人理解起來非常困難，從而造成維護和擴展困難，沒辦法開發出大規模複雜軟件，這就是著名的軟件危機。
爲什麼不用人的思維方式編程呢？一切事物皆對象。人的思維方式就是對象思維。於是人們發明了面向對象編程語言。
面向對象編程有4個優點：可維護性，可擴展性，可複用性，靈活性。
面向對象編程的3個特徵：封裝、繼承、多態。
《大話設計模式》中有一個非常生動的比喻，就是活字印刷術。調版印刷就是面向過程編程，一次性雕刻之後無法修改（維護性）、無法擴展（擴展性）、無法複用（複用性）、無法重新排版（靈活性）。活字印刷術就解決了上面的4個缺點，把每個字做出單獨的模塊（封裝），可以隨意組合成不同的文章和重複使用。所以面向對象編程能很好的應對需求變化。
-
代碼重構
我們一直有一個誤解，以爲使用的面嚮對象語言就是面向對象編程。開發時常常創建一個類之後在“main()”裏面把程序邏輯一次性完成，其實這就是典型的面向過程編程，一旦面對需求變化時就必須修改已有代碼。當然完全不修改代碼也是做不到的，所以我們需要一些編程原則來指導怎麼寫代碼才能最小化修改代碼。
前面提到過“優秀的代碼都是重構出來的”，敏捷開發思想讓我們快速實現功能是正確的，但是遇到變化之後需要對已有代碼先做重構優化，然後才進行業務邏輯修改。大神們已經給我們總結出了經典的重構原則，我們只需要學習掌握就可以了。
重構原則：
- 單一職責原則SRP：只有一個引起變化的原因。
- 開放-封閉原則OCP：軟件實體只能擴展，不能修改。
- 依賴倒轉原則：針對接口編程，不要對實現編程。分層思想。
- 里氏代換原則LSP：子類必須替換掉父類。
- 迪米特法則LoD：最少知識原則。
- 組合/聚合複用原則：多用組合（Composition）和聚合（Aggregation），少用繼承。組合是局部與整體的關係。聚合是包含關係。案例：大雁-雁羣（聚合）；大雁-翅膀（組合）。
- 敏捷開發原則：不要實現猜測和不需要的功能。
這些原則都很抽象，大家自己慢慢研究體會。另外重構也是一個重要的理論，需要配合單元測試來保證重構之後的代碼不影響現有功能。
-
設計模式
鋪墊了這麼久，終於可以介紹設計模式了。所謂設計模式就是人們在重構過程中，總結出來的編程套路。這些套路可以滿足面向對象的4個特性，讓程序能很好的應對需求變化。
經典的設計模式有23種，解決3個方面的問題：對象創建、對象結構、對象行爲，對應的把設計模式分爲3個大類，創建型、結構型、行爲型。
創建型：簡單工廠模式、工廠方法模式、抽象工廠模式、單例模式、原型模式、建造者模式。
結構型：裝飾模式、代理模式、外觀模式、適配器模式、組合模式、橋接模式、享元模式。
行爲型：策略模式、模板方法模式、觀察者模式、狀態模式、備忘錄模式、命令模式、職責模式、中介者模式、解釋器模式、訪問者模式。
每種設計模式都有一個應用場景，解決特定的需求變化，沒有一個萬能設計模式可以解決所有變化。所以我們在學習設計模式時，根據自己的實際需要先掌握一些常用模式。那麼用什麼工具來描述設計模式呢？人們發明了UML來對軟件設計進行描述。設計模式用到了類圖。UML全名叫統一建模語言，一共有3類模型，功能模型、對象模型、動態模型。
UML模型：
- 用例圖：從用戶角度描述系統功能。
- 類圖：描述系統中類的靜態結構。
- 對象圖：系統中的多個對象在某一時刻的狀態。
- 狀態圖：是描述狀態到狀態控制流，常用於動態特性建模
- 活動圖：描述了業務實現用例的工作流程
- 順序圖：對象之間的動態合作關係，強調對象發送消息的順序，同時顯示對象之間的交互
- 協作圖：描述對象之間的協助關係
- 構件圖：一種特殊的UML圖來描述系統的靜態實現視圖
- 部署圖：定義系統中軟硬件的物理體系結構
- 包圖：對構成系統的模型元素進行分組整理的圖
- 時序圖： 表示生命線狀態變化的圖
- 組合結構圖：表示類或者構建內部結構的圖
- 交互概覽圖：用活動圖來表示多個交互之間的控制關係的圖
-
總結
有同學估計要問，我們日常開發工作中有必要搞這麼繁瑣的設計步驟嗎？一會敏捷開發理論，一會面向對象思想，一會重構、設計模式、UML圖等等。我們平時開發工作都是直接擼起袖子就開幹。大師們已經很好的回答了這個問題，有一個生動的比喻，建造一個茅草屋、一個別墅、一個摩天大樓，項目的開發模式是不一樣的。敏捷和架構都一樣，選擇當前最適合的方案，而不是最先進的方案，不要過度設計。
程序員作爲技術人員往往專注戰術層面的問題，如何用最好的技術來實現軟件功能。但是從戰略層次來看，軟件的本質是解決問題的工具，技術也是一種抽象的開發工具。如果想讓自己不成爲只會CRUD的程序員，就需要提升自己的思維層次，站在更高的視角來看待軟件編程這個工作。