2011軟件設計師知識點：構建完整的解決方案
序言：
今天寫的是：構建完整的解決方案。 原因是在過去的幾年中，經常面臨“需求變化”的問題。努力尋找了很多年的解決方案，現在想來，或許問題還是出在我們自己身上，因為我們當初的基礎不對。一句“客戶并不真的清楚自己的需求”，我們真的明白這句話的含義并知道如何應對了么?
什么是“完整的解決方案”?
“完整解決方案”顧名思義，就是包含了客戶的所有真實需求，并可以合理實施的方案。定義很簡單，簡單的像圍棋只有黑白二子一樣，唯一的問題就是：可能的變化多了點，不確定性高了點。
相對圍棋而言，軟件的需求和方案的問題簡單很多了。
主要的問題在于，我們的“需求”中忽略了很多客戶的隱形需求。
隱形需求包含哪些呢?一般而言包括：
1.1 維護需求
1.2 升級需求
1.3 易用性需求
1.4 性能需求
基本而言，現在客戶也在不斷成熟，以上需求會或多或少的提到，但是，請注意，很可能不夠全面。 所以我們需要認認真真的考慮一下，這些需求到底應該包含些什么。
維護需求
客戶對維護的要求，一般至少包括這么幾個：
1. 日志需求。 這個比較復雜，后面會單獨考慮。
2. 故障定位的能力。 就是說，當系統出現問題時，客戶希望系統能夠通過某種方式迅速查明故障的原因，并找到解決或者規避的辦法。
3. 日常維護。 通常包括軟件和硬件的“健康檢查”。
4. 故障報警。 當系統出現嚴重故障時，能夠給出足夠的信息，并觸發故障處理流程。
升級需求
一般來說，客戶對升級的需求有這么幾點：
1. 可控制的升級。 即檢測是否可升級、是否執行升級、多個升級目標的選擇、升級的計劃任務等都是可以控制的，比如可以設定自動檢測是否升級;設定自動升級到***版本;設定執行升級必須為手工設置;設置手工升級時可以立即升級也可以指定計劃任務時間等等。
2. 不影響業務的升級。 基本上客戶都希望升級這個事情，不要影響他們的業務。但是有些系統實在太老了，基于這種舊系統的再開發項目必然受限于原系統的升級方案。這時就考慮：1.能不能通過升級，使系統以后升級不再影響業務;2.如果不能，怎樣使(本次后以后)升級對業務的影響最小。
3. 升級的簡單性。升級應該簡單快捷，沒有太多的參數需要配置，沒有太多需要手工干預的步驟。
4. 升級的完整性。尤其是對于分布式系統，升級時需要考慮各個部件之間版本的一致性。一個升級方案必須是完整的，不能在升級以后出現由于版本間不兼容的原因而導致系統無法工作。舉個例子：
一個簡單的CS系統，采用加密通道進行通訊，現在升級加密算法，該如何設計呢?
假設是互聯網應用，有上萬個客戶端，該如何設計呢?
從這個例子可以看出，系統的設計，從一開始就必須考慮這些“隱性”需求，否則系統架構可能都要****重來。
易用性需求
通常提到易用性，大家會覺得無非是界面啦，幫助啦。沒錯，但是不全。
讓我們看幾個例子，可以大概理解一下易用性是什么概念。
在桌面系統的競爭中，專業而強大的Unix敗給了經常被人批評的Windows系列，因為windows安裝簡單，升級簡單，安裝新的游戲或者軟件也很簡單，操作起來更是如此，直觀的圖形界面雖然設計和功能不太豐富和強大，但是相對于unix必須先學習“文件系統”概念，再學習命令行而言，“樹”的概念用戶可以無師自通，拖拽更是沒有命令行可以比擬;
同樣是微軟，C++語言乘微軟之名，挾操作系統之利，語言和開發環境都不可謂不強大，但是結果怎樣呢?IDE方面多數人還是用SI，語言方面，微軟更是不得不推出C#來與Java抗衡。就因為SI看代碼的時候查找上下文方便;Java比C++開發起來方便;
在中文輸入法的競爭中，強大高效的筆畫輸入法敗給了拼音輸入法?，F在拼音輸入法大行其道，筆畫輸入幾乎鮮有提起。
最主要的，是業務模型要和客戶的一致。這個應該算是基礎。業務模型代表著思維模式(比如輸入法)，也就是說，要從客戶的角度來設計系統，而不是機械的堆砌數據和流程。
一般來言，易用性的需求還包括：
1. 常用的功能應該能夠直接了當的訪問。比如財務系統，不同的角色有不同的常用功能，系統應該設計為可以根據角色來打開不同的初始頁面;再比如我們常見的游戲，Save/Load菜單通常都在主頁面上，沒有誰設計成非得看完片頭(還不能跳過)再新建游戲然后再一路殺到存取點才可以讀取進度。
這里，不推薦嚴格的學術分級模式?；蛟S這樣看起來很專業，但是不好用。
2. 操作應該照顧客戶的習慣，盡可能的降低客戶的學習成本。當然，前提是正確定位你的客戶群。
3. 優雅。舉個例子，log。
寫log的時候，不要一口氣寫個7、8G的log文件，盡可能的根據某些標準來歸類和拆分。例如按照時間，按照log的級別。
還是用MS的VS Studio做例子，編譯錯誤可以直接通過雙擊跳轉到源代碼所在，而不像Makefile那樣只是生硬的輸出文件和行號。
打開一個巨大的文件，給出一個可度量的進度條，總比只顯示一個沙漏要好吧?
現在，應該可以理解什么是“優雅”了吧?我的理解，就是專業，而且體貼。
性能需求
好像現在性能需求越來越被重視了，所以我的廢話也不多說，簡單講，包括：
1. 首先分清楚哪些部分各自有什么樣的性能需求。用戶參與的操作，性能要求通常高于其他操作。
2. 知道自己的上限。達到上限的時候，通過合理的方法讓系統給予提示，而不是直接癱瘓。當然，這是理想主義。只能無限接近，不能達到;
性能是需要設計的，而不是僅靠硬件來實現。所以，在客戶沒有提到性能需求時，你需要通過各種渠道，真正的確定系統的性能要求是什么?！跋茸鲎鲈囋嚒钡慕Y果往往是推倒重來。子曰“有的放矢”是也。
日志需求
***來說說日志需求。
日志需求是和客戶的隱性需求密切相關，并且幾乎全部涉及的一種需求。例如：日志要記錄維護信息和升級信息，日志還要簡單明了，一看就知道寫的啥意思，另外日志記錄功能還不能對系統的性能有大的影響。
【編輯推薦】
