如果是我帶一個團隊做項目我會怎麼做呢？我時常這樣問自己。由於我的想象力比較豐富所以我經常給自己假設這種情景，雖然是假設但是還是些心得體會的，當然這些也是來自實際的工作與學習經驗的總結，也並非完全的臆測所得。
我們都知道，在做一個項目的時候我們首先要做的就是獲取需求。當然項目規劃也很重要，但是那應該屬於項目管理方面的，在這裏我就不提了因爲我不懂這個，雖然最近一直在看這方面的書籍，但是還遠遠沒到能拿出來炫耀的程度，所以我還是和諸位討論下系統設計方面的經驗與體會更實際些。好了，書歸正傳，我們來研究系統設計。現在假設我們已經從客戶那裏獲得了足夠我們啓動項目的需求（因爲談論設計，所以需求獲取的細節就不說了），此時對於不同的人來說可能會走不同的道路，有些人可能會根據已經有的需求直接去編碼實現，當然這些人一般都是剛畢業或者少有項目經驗的朋友常犯的錯誤，或者是美其名曰的“敏捷”，其實敏捷並非沒有設計，其實在敏捷的過程中重構環節恰是他的設計環節，再者敏捷是建立在紮實的技術功底以及豐富的基礎框架或基礎庫的基礎上的，對於一般工作幾年的人或團隊來說是不太容易敏捷的（很有天賦的人除外），如果強行去敏捷反而適得其反；當然還有一種人會至少會做少量但是必需的設計，比如說根據現有的需求畫系統用例圖、畫順序圖、系統框圖等。其實不要小看這些看似簡單的圖，他們的作用其實挺大的，就拿用例圖來說，通過畫用例圖可以使我們對獲取到的需求有更深的瞭解，當然也可以通過用例圖與用戶討論和確認需求。用例圖可能畫的人會多點，但是順序圖就難說了，其實對於某些複雜的通信過程我們可以通過順序圖進行清晰的表達，例如一個客戶端和服務器間不同命令的通信過程，通過畫順序圖我們可以清楚明瞭的瞭解到每個命令的交互過程。最後是系統框圖，我想如果熟悉MVC的朋友可能會很容易理解系統框圖是幹什麼的以及分層設計的好處，通過框圖我們可以將系統分層，爲每個分層定義自己的職責、定義每個分層對外提供服務的接口，各層之間的交互都是通過他們暴露出來的接口進行的。分層的好處是能夠使系統的結構更加清晰，各自的職責更加明確，每層通過各自的接口對外提供服務，而業務的具體實現會對具體的使用者隱藏，這樣當每個層所負責的業務有變更時他們可以更改內部實現而對外的接口並不需要做任何改變，那麼這樣帶來的好處是層與層之間的耦合度自然就降低了，這當然是我們所追求的，因爲這樣我們維護起來會更簡單高效，所以我們在項目的開始是應該離不開系統框圖的設計的。當我們必要的設計都按部就班的完成後我們可以進入下一個階段，對每個層的業務進行分析找到每個分層的核心業務，並將他們作爲系統的關注點記錄下來，因爲這些關注點是決定項目成敗的核心問題，所以我們需要重點突破。比如說我們在做的產品涉及到的客戶端與服務器之間的通信，那麼通信協議的設計就是核心關注點之一，如果我們處理的業務數據量很大，那麼大數據量的處理設計可能就是另一個核心關注點。這樣當我們記錄下所有的關注點後我們就可以有針對性的去設計與解決，當我們解決掉所有的關注點後，剩下的事情應該就是些簡單的業務邏輯之類的，這些其實可以很短時間內搞定的。
有些時候我們可能會進入設計的誤區，可能有人會嘗試設計一個高度智能的系統試圖解決所有的問題，但是很不幸，這樣的系統是不可能實現的，我們能做的只能是針對不同的問題提供不同的解決方案，也有人提出場景的概念，通過定義不同的場景並解決每個場景中的問題，以達到系統高穩定性和高可用性的目的。我覺得這個挺不錯的，通過不同場景的定義我們可以明確不同類型的問題的集合，然後針對每個場景也就是問題的集合制定相應的解決方案，這樣通過對不同的問題場景的解決我們就可以獲得一整套的系統解決方案，其實這個過程也是一種追求不完美的設計理念，因爲試圖解決所有的問題是不現實的也是不可能的。
系統設計感悟：
1、獲取需求，對需求進行分析，列舉將要解決的問題集合；
2、對列舉的問題進行分析，提取關注點；
3、對每個關注點進行細緻的分析；
4、對需求或問題集合進行場景劃分與定義；
5、分別解決每個場景所包含的問題；
6、系統不需要做到完美，而是要做到不完美，解決所有的問題是不現實的也是不可能的；
7、監控和統計分離，好處監控有實時的要求，而統計分析可以不需要實時；
8、可以利用統計分析對用戶對系統功能的使用情況以獲取更準確的系統改進方案或潛在需求；
不完美的哲學：分離關注點，定義不同的場景，分別解決每個場景所面臨的問題！