现代软件工程系列 学生的精彩文章 (4) 为用户服务

赞一下Office的用户体验
今天我做API Hook，开了个Word想截获它的系统调用。结果由于我的程序写屎了，Word一开就崩。崩了大概10次以后，再启动Word的时候它给了这么一个提示：

 
我倒是第一次见到这个对话框，估计其他用户也很少见得到。
用户甚至根本不会想到他需要这样一个feature。比如我要是把Office玩坏了，我就自己重装一遍。即使Office没有这个feature，用户也不会感觉出什么异样，然而M$还是把这样的feature做进来了，要知道，虽然判断一下程序是否频繁崩溃并不难，但是后面的诊断和恢复可能就不那么容易做了（当然我没试过它效果如何）。花这么大功夫去做一些很多用户一辈子都用不到的功能，不得不说Office的开发人员是在很用心的做这个软件，Office不愧是M$的摇钱树啊。
 
另外一个值得思考的问题是，我们写程序，首先关注的当然是程序的正确性，我们都在极力避免程序崩掉，我们可能会忽视了灾难发生时的补救措施。我以前就有这样的心态：我对我写的程序很有信心，它肯定不会出错，所以我没必要写补救的代码以防万一。然而，经历过iHunter的开发以后，我意识到这种想法是片面和不现实的。首先，当程序写到一定规模的时候，谁都不敢拍胸脯保证它不会出错；其次，用户会进行各种各样的非法操作，甚至有删文件等不可抗拒力，写得再好的程序也可以把它搞崩。所以，不管是自己的错还是用户的错，当发生了异常一定要处理，能恢复的就恢复，不能恢复的，至少告诉用户“虽然我不知道为什么会这样，但至少我知道它发生了，建议你接下来做这些事情……”，这比弹出一个“在某某地址读写错误”的用户看不懂的系统错误对话框出来，用户体验要强多了。
 
话虽这么说，但这件事要做好可不容易。我在iHunter里写的代码，经常要跟插件进行交互。对于iHunter主程序来说，插件就是用户了。于是高翔给我的要求是：无论插件给你返回什么样的值，无论它抛什么异常出来，你都不能让主程序崩掉。我写起来才发现要做到这点真不容易。你必须在和插件的每一次交互中都小心翼翼地处理各种异常情况，必须考虑到它会怎样阴你。还有数据一致性的问题，插件一次失败的操作可能把数据给改了，怎样把数据恢复过来？我们现在还不敢夸口说我们的程序坚不可摧，免疫插件的各种耍流氓行为。但我们在尽力处理这些可能根本就不会遇到的问题。如果从应付软工课的角度来看，做这些努力根本是不必要的，因为现在我们的插件都是遵循接口要求写的，根本不会出现各种各样乱七八糟的异常；即使是将来有第三方为我们开发插件，也很难想像它会以搞崩我们的软件为目的。然而，如果是想用心做一个好软件的话，这些工作又的确是不得不做的。
 
-- 黄源河