現代軟體工程系列 學生的精彩文章 (4) 為使用者服務

from:

http://teamkingofcsharp.spaces.live.com/blog/cns!59FC2D3DD66822AA!421.entry

贊一下Office的使用者體驗
今天我做API Hook，開了個Word想截獲它的系統調用。結果由於我的程式寫屎了，Word一開就崩。崩了大概10次以後，再啟動Word的時候它給了這麼一個提示：

 
我倒是第一次見到這個對話方塊，估計其他使用者也很少見得到。
使用者甚至根本不會想到他需要這樣一個feature。比如我要是把Office玩壞了，我就自己重裝一遍。即使Office沒有這個feature，使用者也不會感覺出什麼異樣，然而M$還是把這樣的feature做進來了，要知道，雖然判斷一下程式是否頻繁崩潰並不難，但是後面的診斷和恢複可能就不那麼容易做了（當然我沒試過它效果如何）。花這麼大功夫去做一些很多使用者一輩子都用不到的功能，不得不說Office的開發人員是在很用心的做這個軟體，Office不愧是M$的搖錢樹啊。
 
另外一個值得思考的問題是，我們寫程式，首先關注的當然是程式的正確性，我們都在極力避免程式崩掉，我們可能會忽視了災難發生時的補救措施。我以前就有這樣的心態：我對我寫的程式很有信心，它肯定不會出錯，所以我沒必要寫補救的代碼以防萬一。然而，經曆過iHunter的開發以後，我意識到這種想法是片面和不現實的。首先，當程式寫到一定規模的時候，誰都不敢拍胸脯保證它不會出錯；其次，使用者會進行各種各樣的非法操作，甚至有刪檔案等不可抗拒力，寫得再好的程式也可以把它搞崩。所以，不管是自己的錯還是使用者的錯，當發生了異常一定要處理，能恢複的就恢複，不能恢複的，至少告訴使用者“雖然我不知道為什麼會這樣，但至少我知道它發生了，建議你接下來做這些事情……”，這比彈出一個“在某某地址讀寫錯誤”的使用者看不懂的系統錯誤對話方塊出來，使用者體驗要強多了。
 
話雖這麼說，但這件事要做好可不容易。我在iHunter裡寫的代碼，經常要跟外掛程式進行互動。對於iHunter主程式來說，外掛程式就是使用者了。於是高翔給我的要求是：無論外掛程式給你返回什麼樣的值，無論它拋什麼異常出來，你都不能讓主程式崩掉。我寫起來才發現要做到這點真不容易。你必須在和外掛程式的每一次互動中都小心翼翼地處理各種異常情況，必須考慮到它會怎樣陰你。還有資料一致性的問題，外掛程式一次失敗的操作可能把資料給改了，怎樣把資料恢複過來？我們現在還不敢誇口說我們的程式堅不可摧，免疫外掛程式的各種耍流氓行為。但我們在儘力處理這些可能根本就不會遇到的問題。如果從應付軟工課的角度來看，做這些努力根本是不必要的，因為現在我們的外掛程式都是遵循介面要求寫的，根本不會出現各種各樣亂七八糟的異常；即使是將來有第三方為我們開發外掛程式，也很難想像它會以搞崩我們的軟體為目的。然而，如果是想用心做一個好軟體的話，這些工作又的確是不得不做的。
 
-- 黃源河