摘要：
前文提到我們應該
需求驅動設計，那就直接來乙個更乾脆的做法，我們將需求表示為乙個乙個的使用者故事，
軟體設計
分別針對使用者故事來做就行了，只要將使用者故事逐個實現了，系統也就完成了。果然能這樣做嗎？
大綱：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）要杜絕安全漏洞。
木桶型的設計方法其實會讓系統很難用、彈性很差、工作量更大，而且部分需求我們無法通過新增木條的方式搞定，我們需要盡快公升級我們的設計水平，下一節開始為你介紹比較實用的軟體設計方法。
軟體設計是怎樣煉成的（3） 軟體系統不是木桶型的
摘要 前文提到我們應該需求驅動設計，那就直接來乙個更乾脆的做法，我們將需求表示為乙個乙個的使用者故事，軟體設計分別針對使用者故事來做就行了，只要將使用者故事逐個實現了，系統也就完成了。果然能這樣做嗎？4.1 某種 需求直接驅動設計 的工作方法 案例分析 某敏捷實踐專案小組的設計方式 某專案小組正在如...
軟體設計是怎樣煉成的（3） 軟體系統不是木桶型的
摘要 前文提到我們應該需求驅動設計，那就直接來乙個更乾脆的做法，我們將需求表示為乙個乙個的使用者故事，軟體設計分別針對使用者故事來做就行了，只要將使用者故事逐個實現了，系統也就完成了。果然能這樣做嗎？大綱 1.什麼是優秀的設計？2.優秀的設計能節省專案工作量 3.優秀設計從分析需求開始 4.軟體系統...
軟體設計是怎樣煉成的（3） 軟體系統不是木桶型的
摘要 前文提到我們應該需求驅動設計，那就直接來乙個更乾脆的做法，我們將需求表示為乙個乙個的使用者故事，軟體設計分別針對使用者故事來做就行了，只要將使用者故事逐個實現了，系統也就完成了。果然能這樣做嗎？大綱 1.什麼是優秀的設計？2.優秀的設計能節省專案工作量 3.優秀設計從分析需求開始 4.軟體系統...