zoukankan      html  css  js  c++  java
  • 现代软件工程系列 学生的精彩文章 (4) 为用户服务

    from:

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

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

    image

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

  • 相关阅读:
    zoj 3627#模拟#枚举
    Codeforces 432D Prefixes and Suffixes kmp
    hdu 4778 Gems Fight! 状压dp
    CodeForces 379D 暴力 枚举
    HDU 4022 stl multiset
    手动转一下田神的2048
    【ZOJ】3785 What day is that day? ——KMP 暴力打表找规律
    poj 3254 状压dp
    C++中运算符的优先级
    内存中的数据对齐
  • 原文地址:https://www.cnblogs.com/xinz/p/1889932.html
Copyright © 2011-2022 走看看