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