12年前写的关于程序设计的感想

程序设计

这是个很大的命题，讲述这个的书籍非常多。俺在这里只是说说俺自己的观点。有一次，一个朋友的公司要做一个项目，找我去参谋参谋。到朋友那里时，他们初期的分析阶段刚好结束，接下来打算开始码代码了。那天下午刚进会议室，朋友就很兴奋的给我讲解整个模型，那个是那个的实体类，那个又是那个的工厂，那个继承自那里等等。朋友很high的讲了半小时后，问我有啥意见时。我就说“有主界面和最常用的界面的效果图吗？”。朋友说：“这个还没有，这个具体开发时再找美工做”。我就又问：“用户手册是不是也打算程序开发时再写呢。”朋友也说是这样的。之后我就和朋友讨论这个项目，其实就是一个申报审批的管理，只是中间的流程繁琐，有工作流的影子，又一些行业标准在里边。我建议他：“晚2天再开始具体编码。但是用户手册和效果图要先做一些”。

用户对程序的评价实际上就是来自于用户的体验。简单好用的程序，用户就喜欢。用户手册和效果图实际上就反应了程序的用户体验。程序打算将来带给用户什么样的用户体验，这也是程序设计中很重要的一部分。用户手册恰恰体现了这个。举个最简单的例子。一套合理的快捷键的设置和定义，绝对可以让你的程序好用不止一点点。快捷键能用单个键的就不用组合键、ESC键的处理、上下键的处理、回车键的处理、Tab键的处理等等。这些在开始写代码前就可以到写用户手册中。俺之前处理过别人的一个项目。那个就是火车站的一个后勤系统。客户抱怨很难用，主要是输入时要从几万条中选择一个合适的数据。最初的设计时点击输入框右边的一个小按钮，然后弹出一个查询窗体，然后再输入关键字，进行查询，选中某条数据，然后再点击确定按钮。我给那个系统的诊断就是，直接在输入框里输入关键字，在输入的同时，下面用浮动窗体显示符合条件的数据。并响应上下方向键和回车键的处理。采用了这种方式后，客户说好用多了。为了实现这样的效果，我特意给他写了一个高速的查询方法，因为如果用数据库的全文搜索和like都太慢，在键盘连续按下时有明显的停顿感。我一直认为，尽量减少弹出窗体的使用，因为弹出窗体会带来停顿感，而且也会给用户造成操作步骤繁琐的错觉。当然，我不是排斥弹出窗体，业务上从一个环节到下一个环节的操作，我觉得用弹出窗体比较好。默认值和默认焦点，也是我认为比较重要的。一个窗体在激活时，默认焦点在那个按钮或者输入框里，这个要花很多心思研究。举个简单的例子，那个询问是否执行啥啥操作的提示框，打开时焦点到底是在“是”还是“否”上？我以前的处理时，那种悲观意义的操作，默认是“否”，因为我担心用户不小心连续按住了键盘。这里的悲观意义的操作，我是指“删除”，“封存”，“还原”之类。默认值的处理，一般是日期，选择框之类的，例如日期是默认今天还是下一个工作日，民族默认是汉族（这个人最多嘛）。这些可能你会觉得有点无聊，这些东西没必要写在用户手册中。但是，俺不这么认为。俺觉得。这些有必要和用户交代清楚。程序是用来使用的，只有被使用的程序才有价值，那么程序设计要设计那些呢？首先就应该是这个程序用来做什么和这个程序怎么用，这是项目的负责人要知道自己想要的是个怎样的项目，越清晰越好。俺一直和别人说，项目负责人主要是看对项目的把握能力，如果连自己想要的是啥都模糊，那难免会有偏离方向的时候。所以，有时候，设计程序的架构和模式之前，写两页用户手册是没坏处的。其实用户手册还有一个附加作用。很多的开发团队里，有新手也有熟手，那种刚毕业的写的程序，你看上去可能很郁闷。评价往往是“很多细节有待完善”，你还可以把用户手册当开发规范来用，你可以要求新人写的窗体也要符合用户手册上标出的细节。

效果图也有类似用户手册的效果。好的效果图，能够体现出程序的设计。例如主界面，一个友好的导航能使用户更轻松的使用软件。还有用户最常用的界面一定要设计好，要显示那些信息，那些信息要突出显示等等。而且设计时，最好用实际的数据量，如果是表格，那么一般情况下这个表格是多少条数据，那就做多少条数据的效果。还有不同的分辨率下的效果。还是那个朋友的申报审批系统。每个申报在业务流程中有着复杂的状态。然后操作这些就对应这个无数的按钮和菜单。这点我比较反对，因为这样的设计经常会把人搞晕。

你看看很多游戏，初中生高中生玩一下就上瘾，我们设计的程序连大学生都不知该怎么用。

一个审批单的后续流程很复杂，是的，可能有很多分支。但是这不意味着，要不停的关闭窗体，然后在几十个菜单里

选择不同的菜单，才能继续下一步的。完全可以用一个界面，类似技能树的方式来处理吗，这个小学生都会攀技能树。

默认处理在程序设计中是个很重要的环节。例如窗体打开的默认焦点。一个窗体打开，默认焦点在那里，一定要设计好。

如果是弹出的窗体是 那种多个处理的选择，那么默认的焦点应该就是 根据之前选择的数据，推测的最可能的选择。

合理的快捷键也是程序设计的必须环节。

先写用户手册

有一次，一个朋友的公司要做一个项目，找我去参谋参谋。到朋友那里时，他们初期的分析阶段刚好结束，接下来打算开始码代码了。那天下午刚进会议室，朋友就很兴奋的给我讲解整个模型，那个是那个的实体类，那个又是那个的工厂，那个继承自那里等等。朋友很high的讲了半小时后，问我有啥意见时。我就说“有主界面和最常用的界面的效果图吗？”。朋友说：“这个还没有，这个具体开发时再找美工做”。我就又问：“用户手册是不是也打算程序开发时再写呢。”朋友也说是这样的。之后我就和朋友讨论这个项目，其实就是一个申报审批的管理，只是中间的流程繁琐，有工作流的影子，又一些行业标准在里边。我建议他：“晚2天再开始具体编码。可以先写写用户手册”。

用户对程序的评价实际上就是来自于用户的体验。简单好用的程序，用户就喜欢。用户手册和效果图实际上就反应了程序的用户体验。程序打算将来带给用户什么样的用户体验，这也是程序设计中很重要的一部分。用户手册恰恰体现了这个。举个最简单的例子。一套合理的快捷键的设置和定义，绝对可以让你的程序好用不止一点点。快捷键能用单个键的就不用组合键、ESC键的处理、上下键的处理、回车键的处理、Tab键的处理等等。这些在开始写代码前就可以到写用户手册中。俺之前处理过别人的一个项目。那个就是火车站的一个后勤系统。客户抱怨很难用，主要是输入时要从几万条中选择一个合适的数据。最初的设计时点击输入框右边的一个小按钮，然后弹出一个查询窗体，然后再输入关键字，进行查询，选中某条数据，然后再点击确定按钮。我给那个系统的诊断就是，直接在输入框里输入关键字，在输入的同时，下面用浮动窗体显示符合条件的数据。并响应上下方向键和回车键的处理。采用了这种方式后，客户说好用多了。为了实现这样的效果，我特意给他写了一个高速的查询方法，因为如果用数据库的全文搜索和like都太慢，在键盘连续按下时有明显的停顿感。我一直认为，尽量减少弹出窗体的使用，因为弹出窗体会带来停顿感，而且也会给用户造成操作步骤繁琐的错觉。当然，我不是排斥弹出窗体，业务上从一个环节到下一个环节的操作，我觉得用弹出窗体比较好。默认值和默认焦点，也是我认为比较重要的。一个窗体在激活时，默认焦点在那个按钮或者输入框里，这个要花很多心思研究。举个简单的例子，那个询问是否执行啥啥操作的提示框，打开时焦点到底是在“是”还是“否”上？我以前的处理时，那种悲观意义的操作，默认是“否”，因为我担心用户不小心连续按住了键盘。这里的悲观意义的操作，我是指“删除”，“封存”，“还原”之类。默认值的处理，一般是日期，选择框之类的，例如日期是默认今天还是下一个工作日，民族默认是汉族（这个人最多嘛）。这些可能你会觉得有点无聊，这些东西没必要写在用户手册中。但是，俺不这么认为。俺觉得。这些有必要和用户交代清楚。。程序是用来使用的，只有被使用的程序才有价值，那么程序设计要设计那些呢？首先就应该是这个程序用来做什么和这个程序怎么用，这是项目的负责人要知道自己想要的是个怎样的项目，越清晰越好。俺一直和别人说，项目负责人主要是看对项目的把握能力，如果连自己想要的是啥都模糊，那难免会有偏离方向的时候。所以，有时候，设计程序的架构和模式之前，写两页用户手册是没坏处的。其实用户手册还有一个附加作用。很多的开发团队里，有新手也有熟手，那种刚毕业的写的程序，你看上去可能很郁闷。评价往往是“很多细节有待完善”，你还可以把用户手册当开发规范来用，你可以要求新人写的窗体也要符合用户手册上标出的细节。

用户手册是用来让用户更容易的使用你的软件。你在写用户手册时，会自然而然的站在用户角度上来审视程序。这个角度的转换是很必要的。“坚持以人为本”，十六届三中全会《决定》中明确指出了这一点。貌似好像有点牵强。10多年前，我一个质量控制的程序的用户手册有“第一次使用本系统”这样一章。这个章节标题算是最常见的，内容也更简单，就是说明了系统有自我演示的功能。打开程序后选择“操作演示”，系统就会开始模拟鼠标键盘操作同时有浮动提示。用户就像看电影似的，基本不需要你做啥培训，就会用你的系统。当然也可以用视频之类的，但是那样带入感，要稍微差点。说到这里，不得不说，很多网游在这方面做得很出色。网游的用户手册就是网游本身，他们把导航信息提示之类的做到了很完美的一个程度。还是那个朋友的申报审批系统。那个环节状态很多，我看了就有点晕，我就让朋友学习一下网游。很多网游，初中生高中生玩一下就上瘾，小学生注册后就都会玩。很多公司开发的程序又截然相反，实施时，培训了一天之后，连大学生都不知该怎么用。有的连博士专家都用不会用。我们看看网游是如何处理这一点的。它们的每个细节都有详细的说明显示给用户，下一步到那里，它们都会用脚印或者其他方式提示给你，你跟着脚印走就可以了。需要点击那里，它们就用闪烁的箭头边框之类告诉你。快捷键啥的也是很直观的展现给你。总之，基本只要是进入了游戏，它就带你感受系统的一切，打怪不会他教你，挖矿不会他教你。有点傻瓜机的概念。我觉得这就是地地道道的“以人为本”。貌似有点跑题了，话说回来，先写用户手册只是一种方法，只要一开始就把精力放在怎么捉住用户，怎么让用户感觉到舒服这些方面上就可以。我见过太多的项目负责人，一开始就是整技术框架，然后就是实际开发，中间考虑用户体验的时间不到20%，我不看好这种开发方式。