摘要：
前文提到我們應該需求驅動設計，那就直接來一個更乾脆的做法，我們將需求表示爲一個一個的用戶故事，軟件設計分別針對用戶故事來做就行了，只要將用戶故事逐個實現了，系統也就完成了。果然能這樣做嗎？
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省項目工作量
3.優秀設計從分析需求開始
4.軟件系統不是木桶型的
5.軟件設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——數據庫設計
8.細節決定成敗——詳細設計
9.用戶感覺好纔是真的好——用戶體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
4.軟件系統不是木桶型的
4.1 某種“需求直接驅動設計”的工作方法
案例分析：某敏捷實踐項目小組的設計方式
某項目小組正在如火如荼地實踐敏捷，任務看板上已經粘貼了很多“用戶故事”，項目小組經常在看板前討論問題：
1）討論每一個用戶故事的實現方法，並進行估算；
2）項目小組成員領取用戶故事，負責實現該用戶故事；
3）每天檢討進度情況和遇到的問題。
該工作模式給項目小組帶來了新鮮的動力，調動了大家的工作熱情，取得一定的工作成績，但也帶來了一些思考：
1）只要我們將每一個用戶故事的設計想好並實現，每個用戶故事都能通過測試，軟件就能完成？
2）用戶故事之間沒有關係嗎？軟件設計不需要統籌考慮全部的用戶故事嗎？
4.2 軟件是木桶型的嗎？
請看圖：
![3.1 軟件是這樣工作的嗎？.jpg]()
圖4.1 軟件是這樣工作的嗎？
一般我們的系統會採用分層架構，以三層架構爲例子：
1）最外面的是表現層，主要就是程序的界面了；
2）界面後面就是我們寫的程序；
3）程序後面就是數據庫。
按照上述的“需求直接驅動設計”的工作模式，只要有新的需求，其實就是有新的用戶故事，那麼在這個用戶故事驅動下，直接設計對應的界面、程序和數據庫表就行了。這樣的框架下工作，我們可以無懼需求變更。軟件就是一個大木桶，需要實現更多需求，那就增加更多的木條就可以了；如果要修改需求，那就修改某條木條就可以了！
我發現很多系統是按照這樣的思路來設計的，舉一個某電信網站的例子。
我到該網站交費，發現有免費寬帶提速的服務，需要輸入電話號碼來確認該電話線路是否具備提速的條件。我覺得很鬱悶，明明我已經登錄系統了，系統應該知道我的電話號碼，爲啥還要我填一次？好吧，爲了免費提速，我就輸入一次電話號碼吧，提交後系統告訴我一個訂單號，告訴我大概什麼時候會搞定之類的信息。過了幾天再次上這個網站，免費提速寬帶的窗口又彈出來，我很煩關掉它：我已經提交訂單了，還幹嘛一直提示我！但它又繼續彈出來，我煩了，那再提交一次訂單吧，居然可以提交成功！被這樣的系統折騰幾次其實也不算什麼，只要能免費提速也就值了，但最終的結果是電信一直沒有幫我提速，我也懶得去投訴了，按照我以往投訴的歷史經驗，那是折騰自己的事情！
很多商家在不同時期有很多的促銷等市場活動，需要軟件系統來支持。我們按照木桶原理來做系統的話，看上去似乎事情變簡單，但功能與功能之間其實存在很多交叉點，不考慮這些情況，會導致很多問題：
1）首先是用戶體驗超級不爽。有些系統甚至沒有做到用戶信息和權限信息共享，就好像上述這個電信例子。
2）沒有能發現功能與功能之間的“重用”部分，沒有從架構上和數據庫底層上認真規劃，其實會帶來更大的總體工作量。
3）會留下一些系統漏洞甚至是安全漏洞，萬一出問題後果很嚴重。
4.3 軟件的內部架構是怎樣的？
請看圖：
![3.2 軟件的常見工作模式.jpg]()
圖4.2 軟件常見的工作模式
此圖說明了以下問題：
1）需求並不是由一個個孤立的“用戶故事"組成的，業務概念、業務流程其實是貫穿多個用戶故事的，軟件設計應該多從業務概念、業務流程的角度來思考；
2）表面上看上去一個用戶故事對應一組界面，其實界面之間是很可能有重用和共享部分的；
3）業務邏輯層中的一些類很難將其分拆開來與用戶故事、界面組一一對應，存在交叉、共享和重用的可能；
4）數據操作層的代碼，有可能是用工具自動生成的、通用的；
5）數據層中的某張表，通常會支撐多個用戶故事而不是一個用戶故事。
下面我在列舉一下無法單獨考慮的設計點，以下列出來的可能都需要從軟件架構上做一個整體的考慮：
1）權限控制；
2）性能要求；
3）日誌記錄；
4）工作流；
5）全文搜索；
6）多數據庫支持；
7）搜索引擎優化；
……
實際上很少需求是可以通過單獨添加一些類，加一些數據表就搞定的，需要通盤的考慮。如果我們硬生生地將系統看成是木桶型的，去添加系統的木條，會讓軟件很醜很難用，存在諸多漏洞，而且工作量會更大。
4.4 小結
有時候由於目前能力有限，無法全面考慮需求，只能暫時按照木桶型的方式來設計系統，這樣也不是不可以的，但要注意的是至少要做到：
1）用戶信息和權限信息是共享的；
2）要杜絕安全漏洞。
木桶型的設計方法其實會讓系統很難用、彈性很差、工作量更大，而且部分需求我們無法通過添加木條的方式搞定，我們需要儘快升級我們的設計水平，下一節開始爲你介紹比較實用的軟件設計方法。
前文提到我們應該需求驅動設計，那就直接來一個更乾脆的做法，我們將需求表示爲一個一個的用戶故事，軟件設計分別針對用戶故事來做就行了，只要將用戶故事逐個實現了，系統也就完成了。果然能這樣做嗎？
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省項目工作量
3.優秀設計從分析需求開始
4.軟件系統不是木桶型的
5.軟件設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——數據庫設計
8.細節決定成敗——詳細設計
9.用戶感覺好纔是真的好——用戶體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
4.軟件系統不是木桶型的
4.1 某種“需求直接驅動設計”的工作方法
案例分析：某敏捷實踐項目小組的設計方式
某項目小組正在如火如荼地實踐敏捷，任務看板上已經粘貼了很多“用戶故事”，項目小組經常在看板前討論問題：
1）討論每一個用戶故事的實現方法，並進行估算；
2）項目小組成員領取用戶故事，負責實現該用戶故事；
3）每天檢討進度情況和遇到的問題。
該工作模式給項目小組帶來了新鮮的動力，調動了大家的工作熱情，取得一定的工作成績，但也帶來了一些思考：
1）只要我們將每一個用戶故事的設計想好並實現，每個用戶故事都能通過測試，軟件就能完成？
2）用戶故事之間沒有關係嗎？軟件設計不需要統籌考慮全部的用戶故事嗎？
4.2 軟件是木桶型的嗎？
請看圖：
圖4.1 軟件是這樣工作的嗎？
一般我們的系統會採用分層架構，以三層架構爲例子：
1）最外面的是表現層，主要就是程序的界面了；
2）界面後面就是我們寫的程序；
3）程序後面就是數據庫。
按照上述的“需求直接驅動設計”的工作模式，只要有新的需求，其實就是有新的用戶故事，那麼在這個用戶故事驅動下，直接設計對應的界面、程序和數據庫表就行了。這樣的框架下工作，我們可以無懼需求變更。軟件就是一個大木桶，需要實現更多需求，那就增加更多的木條就可以了；如果要修改需求，那就修改某條木條就可以了！
我發現很多系統是按照這樣的思路來設計的，舉一個某電信網站的例子。
我到該網站交費，發現有免費寬帶提速的服務，需要輸入電話號碼來確認該電話線路是否具備提速的條件。我覺得很鬱悶，明明我已經登錄系統了，系統應該知道我的電話號碼，爲啥還要我填一次？好吧，爲了免費提速，我就輸入一次電話號碼吧，提交後系統告訴我一個訂單號，告訴我大概什麼時候會搞定之類的信息。過了幾天再次上這個網站，免費提速寬帶的窗口又彈出來，我很煩關掉它：我已經提交訂單了，還幹嘛一直提示我！但它又繼續彈出來，我煩了，那再提交一次訂單吧，居然可以提交成功！被這樣的系統折騰幾次其實也不算什麼，只要能免費提速也就值了，但最終的結果是電信一直沒有幫我提速，我也懶得去投訴了，按照我以往投訴的歷史經驗，那是折騰自己的事情！
很多商家在不同時期有很多的促銷等市場活動，需要軟件系統來支持。我們按照木桶原理來做系統的話，看上去似乎事情變簡單，但功能與功能之間其實存在很多交叉點，不考慮這些情況，會導致很多問題：
1）首先是用戶體驗超級不爽。有些系統甚至沒有做到用戶信息和權限信息共享，就好像上述這個電信例子。
2）沒有能發現功能與功能之間的“重用”部分，沒有從架構上和數據庫底層上認真規劃，其實會帶來更大的總體工作量。
3）會留下一些系統漏洞甚至是安全漏洞，萬一出問題後果很嚴重。
4.3 軟件的內部架構是怎樣的？
請看圖：
圖4.2 軟件常見的工作模式
此圖說明了以下問題：
1）需求並不是由一個個孤立的“用戶故事"組成的，業務概念、業務流程其實是貫穿多個用戶故事的，軟件設計應該多從業務概念、業務流程的角度來思考；
2）表面上看上去一個用戶故事對應一組界面，其實界面之間是很可能有重用和共享部分的；
3）業務邏輯層中的一些類很難將其分拆開來與用戶故事、界面組一一對應，存在交叉、共享和重用的可能；
4）數據操作層的代碼，有可能是用工具自動生成的、通用的；
5）數據層中的某張表，通常會支撐多個用戶故事而不是一個用戶故事。
下面我在列舉一下無法單獨考慮的設計點，以下列出來的可能都需要從軟件架構上做一個整體的考慮：
1）權限控制；
2）性能要求；
3）日誌記錄；
4）工作流；
5）全文搜索；
6）多數據庫支持；
7）搜索引擎優化；
……
實際上很少需求是可以通過單獨添加一些類，加一些數據表就搞定的，需要通盤的考慮。如果我們硬生生地將系統看成是木桶型的，去添加系統的木條，會讓軟件很醜很難用，存在諸多漏洞，而且工作量會更大。
4.4 小結
有時候由於目前能力有限，無法全面考慮需求，只能暫時按照木桶型的方式來設計系統，這樣也不是不可以的，但要注意的是至少要做到：
1）用戶信息和權限信息是共享的；
2）要杜絕安全漏洞。
木桶型的設計方法其實會讓系統很難用、彈性很差、工作量更大，而且部分需求我們無法通過添加木條的方式搞定，我們需要儘快升級我們的設計水平，下一節開始爲你介紹比較實用的軟件設計方法。
