你的代码完成了吗?(之一)——可用性和易用性

发表于:2011-10-14 13:18  作者:侯伯薇   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试

  日前,看到在InfoQ上发布的一篇名为《完成宣言》的新闻,其中探讨了什么样的代码才可以算是“完成”了的代码。文中列出了一些标准,大家可以在这里查看相关的内容。

  对于此,我不由地开始反思自己曾经做过的代码,自己是否真的完成了所有的代码呢?自己的代码是否已经满足了一定的标准,真的可以提交给用户使用了呢?其实,现在回顾这些问题有些亡羊补牢的意味,每个人在提交自己的代码之前都应该先问自己一声,这份代码真的完成了吗?

  文中主要是从代码的各种特性来界定代码是否完成的标准的:

  1、代码的可用性和易用性
  2、可维护性和规范性
  3、可测试性和健壮性
  4、从总体上对系统的影响。

  接下来,我想根据自己的一些经验对其再分析一下,同时反思自己。

  一、代码的可用性和易用性

  首先,对于代码(或者说程序)的可用性 和易用性,这应该是最基本的要求。我们的代码开发出来是做什么的呢?不是用来孤芳自赏的,而是要放在业务环境中由业务人员来使用的,也可以说是来检验的。这样的话,可能就有下面的一些要求:

  a)完全实现了业务上的要求,准确地完成了相关的任务。

  b)在性能上表现良好,应该是节省了用户的时间,而不是浪费他们的时间。提高工作效率,他们的感受会很好。

  c)没有太过复杂的操作,即使没有相关的培训,业务人员一眼看上去,大概的功能也就基本了解,并能够很快上手使用。

  这些问题看似比较简单,但是实现起来却需要不少细节上的工作,不信你看下面的场景:

  场景一:业务人员开始抱怨:你开发的东西根本就不是我要的,我一直是这么做的,为什么要让我改变工作的方式?

  这可能会有两种可能,一种是我们在开发的系统中使用了比较先进的管理学理论,改变后的工作方式更有利于业务人员高质高效地完成工作任务,对于此,我们需要和他们耐心的沟通,并劝说他们试验一下,感受一下看看是否能够真正对他们的工作加以改善,一旦他们习惯了,就好了。

  而另一种可能就是,没有达到业务上所需要的,业务上用系统根本就无法工作。这种情况也是非常可能出现的,特别是在国内的项目开发过程中,需求分析和概要设计都没有做好,就匆匆开始编码了。或者说,在看到实际的程序之前,业务人员根本就不知道他们想要的是什么,直到你做出来之后,他们才告诉你那不是他们想要的东西。

  对于这种情况,或者说对于这种项目,都比较麻烦。但是想要改善的话,我有几点建议,一是要加强与客户的沟通。此时XP编程中的一条原则“现场客户”就非常适用。如果我们能够经常地和他们沟通,听取他们的意见,而且在开发的过程中按照“瞄准-射击-调整”的方式,能够少走不少的弯路,也比较容易得到用户的认可。(但在这个过程中就要注意与客户之间沟通的技巧,建议阅读我翻译过的《与客户调情》)。其次是放下程序员的架子,把自己放在和业务人员同样甚至是低一些的位置上,虚心向他们学习,从客户的角度去理解业务流程,想方设法让他们的工作更简单,效率更高,而不是一味地强迫他们按照我们的思维模式去做,毕竟最终的东西不是我们使用。

  在这里一定会涉及到的问题就是变更管理,这也是开发团队和客户之间经常需要“打架”的地方。其实有些时候,如果能够相互理解,不一味地纠缠在钱的问题上,反而更容易解决。试想一下,如果对于每个小的变更都纠缠得非常清楚地话,那么很多时候就会造成之间关系的僵化,从而客户不愿意把相关的业务知识告诉开发团队,那对于我们来说绝对是不可弥补的损失,而且不是能够用Money来衡量的。

  场景二:你这东西也太慢了,本来我做这件事儿需要1个小时,用了你的系统之后需要2个小时,我不得不加班!

  这个没说的,必须要调整了。很多人都收到学校中的一种思想的蛊惑;先把功能实现了再说,性能那个东西可以用硬件来弥补,以后再调整也没事儿。其实,对性能的考虑不仅仅是从开发程序之前就应该开始,而且是应该在整个系统开始之前就开始考虑,包括数据库服务器、应用服务器的设计,数据库中的数据的存储方式、空间的分配等等,都应该在系统开始之前就做了充分的工作,否则等墙快要倒了的时候,再去补,为时晚矣!

  性能应该优化到什么程度呢?我觉得最基本的原则就是,比客户要求的标准稍稍好那么一点儿就可以了,这样他们会觉得你对他们的反馈很重视,并且已经超出了他们的预期,一定会满意的。

  场景三:你这程序界面上的东西太多了,我根本不知道怎么做。而且操作也太麻烦了,要很多步才能完成一项工作。

  在没有完整的信息化系统之前,业务上很多的工作都是使用Excel之类的东西完成的,那是非常方便的工具。但是使用了开发的软件之后,就必须改变原有的工作习惯,比方说回车和Tab的使用,比方说增加新纪录的方式等等;此时就应该尽可能少地把操作的控制暴露给用户,而应该尽可能多地由系统在后台完成工作。如果看到满屏幕都是各种各样奇怪的控件,用户肯定会晕倒的。

  所以说,想要开发出来的程序对于用户来说真的可用、易用,要做大量的工作。并且,随着时间的推移,后期肯定还需要大量的调整工作。

  原文出处:http://www.cnblogs.com/houbowei/archive/2010/03/24/1693425.html


评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道