軟體設計是怎樣煉成的(3) 軟體系統不是木桶型的

2022-03-15 04:27:42 字數 2771 閱讀 1432

摘要:

前文提到我們應該需求驅動設計,那就直接來乙個更乾脆的做法,我們將需求表示為乙個乙個的使用者故事,軟體設計分別針對使用者故事來做就行了,只要將使用者故事逐個實現了,系統也就完成了。果然能這樣做嗎?

大綱:

1.什麼是優秀的設計?

2.優秀的設計能節省專案工作量

3.優秀設計從分析需求開始

4.軟體系統不是木桶型的

5.軟體設計的「大道理」

6.規劃系統骨架——架構設計

7.打造系統的底蘊——資料庫設計

8.細節決定成敗——詳細設計

9.使用者感覺好才是真的好——使用者體驗設計

10.持續提公升設計水平

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)要杜絕安全漏洞。

木桶型的設計方法其實會讓系統很難用、彈性很差、工作量更大,而且部分需求我們無法通過新增木條的方式搞定,我們需要盡快公升級我們的設計水平,下一節開始為你介紹比較實用的軟體設計方法。

創新工場創業課堂(敏捷課程)講師

軟體研發管理資深顧問

cmmi首席專家

《火球——uml大戰需求分析》作者

軟體知識原創基地創辦人

軟體設計是怎樣煉成的(3) 軟體系統不是木桶型的

摘要 前文提到我們應該 需求驅動設計,那就直接來乙個更乾脆的做法,我們將需求表示為乙個乙個的使用者故事,軟體設計 分別針對使用者故事來做就行了,只要將使用者故事逐個實現了,系統也就完成了。果然能這樣做嗎?大綱 1.什麼是優秀的設計?2.優秀的設計能節省專案工作量 3.優秀設計從分析需求開始 4.軟體...

軟體設計是怎樣煉成的(3) 軟體系統不是木桶型的

摘要 前文提到我們應該需求驅動設計,那就直接來乙個更乾脆的做法,我們將需求表示為乙個乙個的使用者故事,軟體設計分別針對使用者故事來做就行了,只要將使用者故事逐個實現了,系統也就完成了。果然能這樣做嗎?4.1 某種 需求直接驅動設計 的工作方法 案例分析 某敏捷實踐專案小組的設計方式 某專案小組正在如...

軟體設計是怎樣煉成的(3) 軟體系統不是木桶型的

摘要 前文提到我們應該需求驅動設計,那就直接來乙個更乾脆的做法,我們將需求表示為乙個乙個的使用者故事,軟體設計分別針對使用者故事來做就行了,只要將使用者故事逐個實現了,系統也就完成了。果然能這樣做嗎?大綱 1.什麼是優秀的設計?2.優秀的設計能節省專案工作量 3.優秀設計從分析需求開始 4.軟體系統...