在談架構師分內的事情之前想先談談為什么要做架構，這個問題其實挺有意思的，一種是被動的一種是主動的。被動的做架構設計是因為設計者內心並不太願意去做設計，不願意做設計的原因挺多的，比如，項目開發周期短，覺得沒有足夠時間去做設計。或者，認為設計很麻煩，除了UML設計、設計文檔之類的還有設計評審什么的。或者，覺得設計沒什么作用，屬於浪費時間。或者，不懂設計，不知道如何下手等原因，不一而足。雖然內心不情願，但由於一些外部原因，卻又不得不去做設計，比如，是公司規范要求，有些公司是按照CMMI規范的，必須要有設計文檔，或者，是領導要求做設計等等原因。總之，這種被動的設計會帶來很多問題。
- 走形式，只是為了應付檢查或者為了完成任務。這樣可能出現一些比較奇怪的事情，先開發后補設計文檔，往往是開發完成之后才寫設計文檔，我曾經就看到過這樣的事情，這樣導致的結果是，沒有設計，設計只是為了生成一個設計文檔。還有一種情況就是東拼西湊幾個圖和幾段文字組成一個所謂的設計文檔，這其實只是僅僅是形式上的設計文檔，因為很多公司都找了一個所謂的標准的設計文檔模板，設計者只要填充其中的內容即可，填充完了就是設計完了，這種設計文檔模板和八股文非常相似。設計者或許都不太清楚為什么要這樣設計，只知道按照八股文的作法去填充，只是因為文檔要這些東西。這樣導致的后果是，設計者迷迷糊糊，開發者更是不知所雲，這樣導致的結果是，設計是設計，開發是開發，二者沒有任何關系，僅僅是為了完成任務。
- 本末倒置，設計的目的是為了梳理業務邏輯、解決開發過程中可能遇到的問題，使我們的開發工作變得容易，目的是指導開發，提高軟件產品的品質。設計不是為了生成文檔，不是為了應付檢查或者完成任務，否則就是本末倒置，也失去了設計的意義。
不願意做設計的原因很多，但是最重要的原因是沒有體會到設計的重要性，不知道為什么要做設計，以為設計就是幾個圖和設計文檔，繁瑣而無大用，心底是有些排斥的。為什么要做設計？這個問題很重要，很多人說我很少或者幾乎不做設計，但是我一樣完成了項目的開發，以此證明設計或者不設計都可以，是無所謂的。是的，不設計一樣完成開發項目，這種事情很普遍，我看到不少項目，沒有任何設計文檔，因為根本就沒有設計過，內部的對象關系如同蜘蛛網一樣，而且隨着新需求的增加，代碼就變得更加混亂了，這樣帶來的后果是修改或者擴展都很困難，不能快速響應新需求。另外，別人維護時，很難看懂代碼的意圖，如果要了解其含義，不得不查看大量的代碼，還不能確保一定理解了原來的思路，這樣帶來的問題是可維護性非常差，而且修改很容易破壞原有結構，使代碼變得越來越難以理解和難以維護。這樣的軟件產品，表面上看似乎還在運行，但是內部遍布着坑，bug難以查找和解決，改了這里就錯了那里，改一個地方還不行，還要改一系列的地方，直到某一天，發現這樣做下去太痛苦了，不僅不能快速響應市場，原來的維護還很費勁，最后不得不推倒重來。我這里並不是說不做設計的項目一定會糟糕到這個地步，如果你的項目，雖然沒有經過設計，卻仍然運行得很好，那我可以說你的運氣很好，也許是沒有遇到需求的變更，也許沒有遇到挑剔的用戶。如果你做的好幾個項目都沒有設計仍然運行得很好，那我就只能說你對產品和業務真的很精通，開發即設計乃神人，我等凡人可望不可即也。但我仍然想說的是，如果你是凡人且繼續根據經驗主義不做設計就去開發的話，那遲早要栽跟頭！
為什么要做設計，關於這個問題我想以我的一點經歷來說說，以前做過一個項目，這個項目比較小，正常情況下，兩個人大概兩周多就能做完，也許以為項目很小，能很快完成，就沒有做設計，我覺得業務邏輯不復雜，能夠在開發的時候設計好，於是直接就開始做了。項目是做一個統計庫給前端使用，統計庫主要是根據一些統計類型來統計，根據這個特點，開發時將每個統計類型抽象成一個統計類，這是個比較典型的策略模式，第一周做得還比較順利，完成了60%，第二周的時候發現有個有個特殊的業務類型需要處理，這個業務類型可以嵌套多個其它的業務類型，這時，已經感覺策略模式就顯得不那么合適了，但想着只是一個特殊情況，就特殊處理吧，在策略模式中再增加一些條件判斷些用來處理嵌套統計類型，隨着后面開發和測試不斷的深入，又發現有幾種特殊情況要處理，看着開發時間都過半了，也不願意大改了，想盡快完成任務，於是，又是在一些策略類中加判斷，導致本來可以復用的嵌套統計代碼都不方便復用，調試起來也很不方便，最后回頭來看，程序結構顯得混亂，還有不少重復代碼，沒有美感可言，顯得很丑陋，隨着后面新需求的不斷加入，代碼已經變得難以擴展和修改了。
為了不使代碼繼續腐化下去，就不得不停止開發，從架構上重構了。重構的時候我不再直接開發，而是先做設計，通過對業務流程進行分析，將業務的流程歸類出來，充分的了解業務過程是什么樣的，再結合業務流程圖做用例分析，通過用例分析來確定我們的我們的系統到底有多少用例，用例之間的關系是怎么樣的，最終畫出系統的用例圖。業務建模結束之后邀請產品人員幫忙分析，業務流程的歸納是否合理，業務用例是否涵蓋了所有的用例。業務建模階段使我完全明白了整個業務流程和細節，這為之后的設計帶來非常大的便利。之后，我再根據前面的業務建模做系統分析，根據包的設計原則和單一職責原則划分組件，將各個組件的耦合性降到最低，組件划分好之后再進行類的設計。類的設計時考慮到要解決嵌套統計的問題，就不能再用策略模式了，改成橋接模式和組合模式，這兩個模式結合起來可以完美的解決嵌套統計的問題，關於他們結合的細節可以參考我前面的介紹：composite模式和bridge模式是天生的好朋友。這個設計大概花了將近一周時間，不過這個設計只是UML設計，不包括設計文檔，因為時間比較緊，UML設計文檔轉換為word設計文檔的工作並沒有做。在UML設計完成之后就開始開發了，開發階段非常順利，開發時間實際上只花了一周時間。重構后，整個架構非常清晰，由於都是單一職責的，沒有重復邏輯，修改起來也很方便，且完全可以靈活的應對新增需求，符合開閉原則。
也許有人要說，這是由於我沒有深入了解業務導致設計不合理的導致的結果。是的，是我沒有深入的學習業務，在開發階段草率的做出了不成熟的抽象和設計，導致后面特殊業務規則出現時，不能適應變化。但是，這個問題其實完全可以在設計階段就可以發現，從而可以避免在開發過半的時候發現問題而大改。如果一開始就做設計，然后將設計推銷給產品工程師，推銷給開發者，很多問題就能及早發現，而不是邊開發邊設計，導致不能從整體上去把握。邊開發邊設計，往往還導致頭痛醫頭腳痛醫腳，結構混亂，使開發變得困難，最后還受限於開發時間而不得不沿錯誤的方向走下去，最終做出一個失敗的產品。
很多時候我們不可能一下子就了解全部的業務，這需要一個學習和消化的過程，而設計階段就是將業務變為軟件實現的過程，這個過程是業務的充分消化吸收的過程，這個過程如果順利通過，則后面的開發就會變得非常容易，因為設計到類圖了，而且在設計階段將已經將絕大部分問題都解決了，剩下工作只是如何完成這些具體的類而已。這個經歷給我很大的啟示，哪怕是一個一兩周的小項目也要做架構設計，因為設計可以幫助我們梳理業務邏輯，避免因為業務邏輯的不熟悉而導致的不合理的抽象和歸納，不合理的抽象會導致架構不能應對正常的變化，還難用，開發也變得不順利，輕則導致開發延期，重則項目失敗。
關於設計的目標，架構設計看似耽誤時間，實際上為了將業務邏輯合理的組織起來，解決開發階段會遇到的問題，並最終指導開發順利的完成。如果設計不是用來指導開發，或者對開發來說沒有作用，甚至起反作用，那么設計對於開發來說就是無用的，這個設計做得也是失敗的，是浪費時間的。設計是為了解決開發過程中會遇到的問題，並最終指導開發的，如果沒有達到這個目標，那么這個設計就是失敗的。
關於設計的時間，以我上面的那個重構項目為例，設計花了一周時間，本來按照正常的開發周期來說，一周時間肯定是不夠的，因為除了UML分析之外還要編寫設計文檔。但是由於項目很小，且開發周期很短，我就只做了UML設計，然后后面的開發都是依據UML設計去開發的，UML設計轉化為文檔的工作就省掉了，這節省了不少時間，這樣做是否合適呢？我覺得在一定程度上是沒問題的，因為UML設計本質上就是已經完成了的架構設計，一圖勝千言，UML圖本來就是程序員交流的介質，方便開發者交流和理解，也能方便的指導開發，僅僅做UML設計對於項目開發來說沒問題，不過對非專業的技術人員來說可能顯得過於抽象和難懂，這時才需要將UML抓換為word文檔，通過文檔詳細解釋UML設計。架構設計看似慢，實則快，不管項目多小，都要做設計，好的設計不僅可以指導開發還可以加快開發，是非常有必要的。
關於設計和文檔，有很多人將二者混淆起來，認為設計就是文檔，其實二者不是密不可分的，關鍵是設計，文檔是對設計的解釋和描述，架構設計的精髓在於UML設計，通過幾張UML圖就能清晰而深刻的表達設計思想，一圖勝千言，設計不是為了生成文檔，文檔只是設計的結果而已，很多人本末倒置，以為像八股文一樣填充好設計文檔就是完成了設計，這是非常錯誤的想法。我更喜歡看UML圖而不是看文檔，因為文檔啰嗦半天都趕不上一張圖直接。開發人員應該通過UML設計文檔而不是word文檔來開發，UML設計簡短而直接，一來可以清楚的知道自己所開發的東西是整體架構的哪一部分，該如何開發；二來可以更深入的理解架構，減少破壞架構的失誤。
未完待續...