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