软件随想录[教育]

软件随想录[教育] 软件随想录 易用的界面，简单的一步 ( 第一稿 ) 作者:周思博 译者:Shao Fan 原作日期:2006年3月9日 在飞机控制的设计中，糟糕的可用性会致使飞机发生CFIT:可控飞行撞地。 可能可用性在你的产品中不是那么关键。如果幸运的话，你在可用性设计中的错误可能只会使人失去四肢，或甚至只是拇指。没什么更糟的了。 事实上，如果极端幸运，那么糟糕的可用性设计除了会使人难受，没有其他后果。用户试着去做一些事情，或者失败，或者挣扎着去用，很直接的后果就是他们会为此感到不悦。在将来的文章里，我会讲讲此事在心理上的原因，但现在，这样说就足够了:使用户不悦的原因，很可能并非完全如你所想。 可用性，确实是一个“好”设计的核心。在将来，我会花很多时间来讲述这个问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。 好消息是:我可以很轻松地教你关于可用性设计的话题。让我们开始吧: 当一件东西能够以被期待的方式运行，那它就是易用的。 就是这样～这就是关于可用性的一切～像Hillel所说，其它的一切都是解说词。 让我们来看一个简单的例子。 哪个更好用:Windows还是Mac? 在为人们设计产品时，有一个假想用户是很有帮助的。所设想的用户越是实际，提供的帮助越大。 我的假想用户就是彼特。 有一天，彼特的朋友，吉娜叫他来帮忙。吉娜有一台Macintosh的iBook，因为她喜欢白色的电脑。当彼特坐下开始试着用吉娜的Macintosh时，他很快就感到有点沮丧了。“我讨厌这些东西，”他说。虽然最后成功地帮吉娜解决了问题，他却觉得高兴不起来。“Macintosh的用户界面真是笨拙至极。” 笨拙,为什么会这样说呢,每个人都知道，Macintosh有着优雅易用的用户界面，对不对,难道它不是那种易用性的范例吗, 好吧。让我们来看看。 在Macintosh上，如果你想改变窗口的大小，你必须拖它的右下角。而在Windows上，在任何一个边上拖动鼠标，都可以改变窗口大小。当彼特帮吉娜时，他试着拖右侧的边来让窗口变宽。结果，整个窗口都跟着动了，而不是他想要的“改变大小”。 在Windows上，当出现一个消息框时，你只要按tab键移动焦点到所需的按钮上，然后按一下空格键就可以按到那个按钮。但在Mac上，空格键不起那样的作用。当彼特得到一个警告，他就试着像他过去六年里下意识的做的那样，按空格键来关掉消息框。第一次，机器没有任何反应，他以为是键盘有问题，于是更大力地又按了一次。结果还是一样。最后他只能用鼠标了。这是另一个小小的挫折。 彼特还习惯用Alt+F4来关闭窗口。在Mac上，这恰恰是用来调整声音音量的。这次，彼特想点击桌面上的IE图标，而这个图标刚好被另一个窗口遮住了一部份。于是他按Alt+F4关闭窗口的同时立即双击图标所在的位置。结果是声音音量变大了，而窗口并未被关掉。而他的双击点在了他想关掉的那个窗口的帮助按钮上，把帮助窗口打开了。好了，他现在需要关闭两个窗口了。 这也是一个小小的挫折吧，但是，这确实让彼特更加郁闷了。这天结束的时候，彼特的脾气很不好。他试着控制那些东西，却都没有反应。空格键和Alt+F4都“不起作用”----就像它们坏了一样。窗口也不听话，连调整大小都不行。真差劲。就算这些想法都是下意识的，这些“失去控制”的细微感受也最终使他感到不快。“我还是喜欢我自己的电脑”，彼特想，“它被我设置的完美无缺，总能按照我想的方式去运行。而这些Mac真是难用。真是让人不爽。如果Apple这些年多花些心思在MacOS上，而不是搞iPod那些玩意，他们的操作系统也不会这么糟糕了。” 好了。我们比彼特清楚。他虽然有这些种种感受，但事实上对Mac用户来说，Mac确实很好用。完全可以用任意键来关闭窗口。微软的程序员很可能觉得，让用户拖动任意边都可以调整窗口大小的功能真的很不错。而Apple程序员很可能认为，拖动任意边来移动窗口位置的功能很有创意。 那些盲目信仰某种OS的网站上的关于用户界面的争论，都没有说到点子上。Windows更好，是因为给你更多手段来调整窗口大小。那又怎样,这并不是问题所在。真正的问题是，UI是否以用户预期的方式来响应他们的操作。如果不是，那么用户就会觉得他们无法控制它，并觉得自己会难以达成目的。就是这样了。当一件东西能够以被期待的方式运行，那它就是易用的。你可以把这句话反着纹在你的额头上，这样你在镜子里就可以看到它。 如果你继续关注将来的文章，那么你会发现，我所告诉你的关于可用性设计的一切，都可以追溯到这个简单的法则。如果哪天外星人在你的花园里着陆，把你扔到了名叫Kij8zxwrk的星球，在那里你无法连接到地球的互联网，因为数据包传送到地球所花时间太长导致TCP/IP无法正常工作，那么你所知道的东西也足以让你找到一份相当体面的可用性设计师的工作了。 主次分明 2005年10月12日 周思博 我们总算要结束调整FogBugz 4.0而开始开发FogBugz实行5.0了. 我们刚发行了挺大的更新,修复了成千上万的从没人注意过的小错误(当然也加入了几个没人会注意的新的小错误). 现在我们要开发一些超越时代的新功能了. 当我们准备就绪开发5.0的时候,我们已经准备了足够的点子让1700 个程序员忙上个几十年. 很可惜,我们只用3个程序员,预定的发行日期又是明年秋天,所以我们一定要分分主次,区分优先. 在我告诉你我们怎么区分优先之前,我先得告诉你两个错误的方法: 第一,如果你发现自己加入一个新功能的唯一的原因是你答应过一个客户,你脑子里立刻得亮起红灯. 如果你只是为了一个客户而操劳,要么你有个说话不家思索的推销员,要么你慢慢的已经变成了咨询服务了.咨询服务没什么不好,也可以过好日子,只是咨询服务没卖包装软件赚的那么多. 包装软件的特色就是要就要,不要就不要.你开发了一个软件,包装起 . 你不来,客户要么买,要么不买.他们不会讨价说再加一个功能就买会打电话个微软说:”我很喜欢EXCEL里面能够自动的输出泰文的数字的功能,可不可以弄个英文版的?”. 你如果这么问了,他们会回答:”谢谢你给微软打电话,你如果是广告咨询;按1.如果要技术咨询,按2;如果你想要注册咨询,按3; 如果你知道你想找的人的分机号码,按4.从头开始,按星号.” 看到了吗? 他们根本不给你选择要加一个新的功能. 个人化的开发就是一个客户告诉你加入什么功能, 你说:”你确定要吗?”;他们回答:”确定的”;你立刻写了一个很漂亮的开发计划,问他们:”这样可以吗?”,他们说:”可以的”. 你让他们在合约上签名,或者画个血书,他们也干. 然后你开始完全按着计划一步步的开发,可成品出来他们却大吃一惊.之后一个星期你得和公司律师商量是否有足够的法律保护和这客户打官司,或者就和客户私了了. 运气好的话,你的客户很好说话,他们把这新的东西藏到抽屉里,再也不会拿出来用; 当然他们再也不会当你的客户了. 个人化的软件和包装软件之间还有咨询软件. 咨询软件貌似包装软件,可只给一个客户用. 咨询软件的特色是: 1) 你超级廉价的给一个皮鞋厂写软件. 2) 那皮鞋厂需要一个擦皮鞋的软件. 3) 你用VB 3.0写了个擦皮鞋的软件. 当然中间也加了点JavaScript, 一点Franz Lisip和一个连在一个旧的MAC上的File Maker的数据库. 4) 每个人都有创建自己软件公司,成为下一个Bill Gates或者Larry Ellison的梦想. 5) 你从公司买下了” 擦皮鞋1.0”的版权,找到了几个投资人,创建了”擦鞋软件公司”, 6) 可惜的是没有一个BETA测试人可以运行你的软件,那源程序真是太复杂了.每个客户都得花上你一个月的时间来安装和调试. 7) 你的软件又贵,又有很多千奇百怪的 要求 对教师党员的评价套管和固井爆破片与爆破装置仓库管理基本要求三甲医院都需要复审吗 ,所以你也没什么客户. 8) 你开始给你的销售部门加压. 9) 你的销售部门发现擦皮鞋的软件现在不流行了,不过有一个客户想要一个烫裤子的软件. 10) 销售部门立刻和他签了100,000美元的和约. 11) 你又花了6个月的时间改写” 擦皮鞋1.0”,让它支持烫裤子的功能. 12) 当然了,没有其他客户需要这个新功能. 13) 归根到底,你花了一年的时间成为了那个烫裤子公司的廉价劳动力. 14) 回到(1) 个人来讲,我是强力推荐你只开发包装软件. 卖包装软件给一个新的用户对你来讲没什么额外的开支. 你只是把同样的东西一次次的卖出去,然后赚取利润. 因为客户多了,你可以减低价钱; 而价钱越低,客户也就越多. 大家的日子都很好过. 所以说如果你花时间为一个客户加入什么新功能的话,你基本上就是离开了包装软件而进入个人化的开发和咨询软件的地域了. 当然了,如果你喜好那样,也没什么不对. 只是不管怎样,放在货架上的包装软件是最赚钱的. 我不是说你不该听你客户的意见. 我就认为微软早该把那个自动输出泰文的功能普及到其他文字了.全世界不说泰文的可不少人呢. 也许你认为你应该把开发资源放在让你最大的客户身上; 说到底他们钱最多吗. 可你最终会发现你大多客户和你最大的客户需求不一样. 对Arizona州里一些小客户来讲,自动输出泰文的功能跟本和他们没关系. 帮最大客户开发只和他们有关的东西只有让负责那个客户的销售经理出风头而已. 这条路是不会让你成为Bill Gates的. 好了,现在让我告诉你第二种错误的方法. 不要因为你避不开了才去 开发某个功能. “避不开了”不是一个足够好的理由. 在我刚开始Fog Creek的时候,有一天我在整理文件的时候发现蓝色的文件夹用完了. 我整理文件有个系统, 蓝色的文件夹是和客户有关的; 乳白色的是职工的; 红色的是收据; 其他都是黄色的.那天,蓝色的用完了. 我对自己说,蓝色的文件夹总是需要的,我顺便去Staples买一些吧. 真是浪费时间! 我常找借口给花园除草, 补补墙上的洞, 按颜色,语言,号码整理MSDN的光盘. 我可是个刚开始的小公司的人啊,我所有的时间应该就是编写程序和卖我们的产品. 换句话讲,我自欺欺人的告诉自己那些浪费时间的事情也很重要.所以我就主次不分的把那些事情给先做了. 说实话,我只是在拖延时间啊. 我该怎么做呢? 第一,我根本不用按颜色来选文件夹,那真的没什么用. 还有那些MSDN的光盘,找个大盒子装一下就好了. 最主要的是我该认识到重要不是二分的,重要是一种程度,有很多不同的级别.如果你每件事都想做,你什么也做不成. 每日构建(daily build)是你的朋友 作者: 周思博 (Joel Spolsky) 译: Chen Bin 2001年1月27日 1982年，我家定购了IBM的PC机(IBM生产的最早的个人计算机，是现代流行的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 化的个人计算机的祖宗)。我们家可能是以色列最早拥有这种PC机的几个家庭之一。当时我们跑到了仓库等着电脑从港口运过来。事实上，我说服我爸购买的是带有全套附属设备的个人计算机(译者按:有些现在很便宜的附属设备，那时候都是非常昂贵的)，这些附属设备包括两个软盘驱动器，128K内存，一个针式点阵打印机(用来快速打印草稿)和一个运转起来发出机关枪扫射声音的兄弟牌的雏菊轮式打印机(译者按:原文为Daisy Wheel printer，是一种已经淘汰的打印机，原理类似于老式的机械打字机，可以产生清晰的英文字符)。附属的软件也很齐全，PC-DOS 1.0(最早的PC操作系统)，75美元的参考书册，包括BIOS的完整源代码。 一个汇编语言编译器(Macro Assembler)，非常棒的IBM单色显示器，可以显示80列宽的字符，而且支持小写字母显示。整套配置大概花了10000美元。这些钱包括以色列的荒谬的进口税。呵呵，那时候我家可真舍得花钱啊～ 因为当时“每个人”都知道BASIC是给小孩玩的语言，用这种语言只能使你写出非结构化的垃圾代码，然后你的的脑子也会被这种语言变成Camembert产的奶酪(Camembert cheese，法国的一种奶酪，实心，圆饼状，灰色，有一个拳头大小)。所以我们又花了600美元买了一个IBM公司PASCAL语言开发包，需要3张软盘才装的下。PASCAL编译器运行分别需要第一号软盘，和第二号软盘，PASCAL链接器需要第三号软盘。我写了一个简单的输出文字“你好，世界”程序然后编译链接这个程序，总共花了8分钟。 嗯，8分钟好像太长了。我写了一个脚本程序来自动化整个过程，把时间缩减为7.5分钟。这样好一点了。但是我想设计一个可以玩奥赛罗的程序。(译者按:奥赛罗原文为Othello，一种棋类游戏，规则见)这个游戏总是能打动我。 我不得不花很多时间等待编译器编译我的程序。“就是这样的，”一个专业程序员告诉我，“我们通常在办公室里房放上sit-up board(译者按:一种健身器材，可以在上面做仰卧起坐或者有氧操什么的) ，当PASCAL编译器开始运行时，我们就开始锻炼。我这样编程了几个月后，我的身材不要太棒喔～” 后来有一天，丹麦程序员写了一个很灵的叫做Compas Pascal的程序。Philippe Kahn(Borland公司的创始人)买下了它，更名为Borland Turbo Pascal。Turbo Pascal好得简直难以想象，因为它能做IBM Pascal能做的所有事情，但是只要33K内存。而且还额外提供一个编辑器。 这还不是最棒的。最棒的是编译一个小程序只需要不到一秒。这就好比一个你从来没有听说过的公司生产了通用公司别克轿车的克隆版，这种克隆车可以每小时行驶一百万英里，但是只消耗了一滴汽油。一只小小的蚂蚁喝下这点汽油也不会撑死。 突然，我的编程效率变得高的多了 那时我开始明白了“REP循环”(Rep loop)这个概念. REP是“读入，求值，打印(Read, Eval, Print)”的缩写。这个概念解释了Lisp(一种编程语言，用于人工智能)解释器的基本原理:它“读入”你的输入，计算你的输入得到结果，打印结果。下面给一个例子:我输入一些东西，Lisp解释器计算，然后输出结果。 在一个稍微大点的规模上，当你写代码时，你也处于一个REP循环的宏版本中，这个循环就是“编码,编译,测试”。你编写代码，把代码编译成可执行的文件，然后测试它，看一下运行起来怎么样。 关键一点是当你写一个程序时，你的工作过程是循环的。一个循环所花时间越短，你的生产力就越高，当然最短时间不会小于编译器运行的时间。 这就是一个程序员为什么总是要一个真正够快的硬件而编译器开发者们总是不断使他们的编译器运行更快的正式的纯计算机科学角度的原因。Visual Basic的办法是当你输入代码时，它就开始进行代码的语法解析，这样程序解释运行时速度很快。Visual C++的办法是增量编译(incremental compiles)，预编译头文件(precompiled headers)和增量链接(incremental linking)。 但是一个大型的团队有多个开发人员和测试人员，你碰到了同样的循环，可能不同点就是有更多的文档要写(可是这还只是草稿，天哪～)。一个测试人员发现了bug并 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 ，然后开发人员修复了这个bug。那么测试人员得到修正后的代码需要多少时间,在一些软件开发机构，这样的报告,修正,再测试循环(Report-Fix-Retest loop)可能需要几个礼拜。如果一个循环需要这么长的时间，通常意味着该机构生产力很低。想让整个开发过程运转得更平滑一点，你必须想方设法使得报告,修正,再测试循环(Report-Fix-Retest loop)花的时间更少。 一个好的办法是每日构建(daily builds)。 每日构建意味着自动地，每天，完整地构建整个代码树、(译者按:“代码树”，原文为source tree，意思是将整个项目源代码的目录，子目录，文件的位置尽可能事先固定下来，这样在开发过程中各个模块间，各个文件间的相对位置都不会混乱。源代码树指的就是一个项目所有的已经组织好的代码文件。通常代码树应该用版本控制软件管理起来。虽然这个概念很基本，但是据我的观察，国内还是有软件公司在这方面做的不够好的，所以有必要解释一下。) 自动地 , 因为你设定代码每天在固定的时间构建。在Unix环境下 使用cron，在windows下使用“任务计划”。 每天 , 或者更频繁. 当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和版本控制有关系，等会儿我会谈到的。 完整地 ,很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建(daily build)需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增量编译功能。 以下是每日构建(daily build)能带来的好处: 当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地被修复了。 开发人员可以更加确定他们对代码做的修改不会破坏1024个操作系统上的任何一个版本。验证这一点不需要在他们的机器上安装OS/2(IBM公司生产的PC机操作系统)。 那些每天将修改过的代码导入(check in)版本控制服务器的开发人员知道，他们对一个模块导入的修改不会拖别的开发人员的后腿。拖后腿的意思是，那些开发别的模块的程序员使用这个修改过的模块，出了问题，于是他们自己的模块也没有办法开发下去了。每日构建则不会有人拖后腿。如果把一个开发团队比作一台PC机，那么团队中的一个程序员对某个模块的修改导致其他人无法开发别的模块，相当于PC机发生了蓝屏。当一个程序员忘记把他(她)新建立的文件导入到repository(指版本控制服务器上的代码树)时，这种开发过程中的“蓝屏”会经常发生。因为在这个程序员自己的计算机上有这个文件，所以他(她)构建 这个程序没有问题。但是其他程序员是从版本控制服务器上导出(check out)代码的，由于服务器上没有这个文件，他们遇到了链接错误(link error)，无法继续工作了。 外部团队(例如市场销售部门，进行beta测试的一些客户)可以获得一个比较稳定的版本，这样对他们开展自己的工作 比较有利。 假如你将每日构建出的二进制文件(例如一个可执行程序，一个dll等等)存档管理，那么当你发现一个非常奇怪的，无法解决的bug时，你可以通过对这些文件进行二进制搜索(binary search)来确定什么时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导入(check in)导致了这个bug。 当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人员可以直接在那个版本中测试是否bug真正被修复了。(译者按:测试者报告出现了一个bug，只是报告了一个错误症状，而错误的原因可能有多个，每个原因可能在不同的模块中。前文中的方法是为了避免只修正了一个模块中一个原因，别的模块由于在变动，于是掩盖了而不是修复了bug) 以下是如何进行每日构建(daily build)的具体步骤。你需要用最快的电脑建立一个每日构建服务器。写一个脚本，可以自动从版本控制服务器中导出(check out)完整的代码，(你当然使用版本控制，不是吗,)，然后对代码从头开始进行构建(build)，要构建所有的版本。如果你有一个安装打包程序，也要在脚本中自动运行。所有会卖给最终用户的东西都要包括在构建过程中。把构建出来的版本放在各自的的目录里，不同时间构建的相同版本也应该按日期整理好，不要相互覆盖。每天固定的时间运行这样的脚本。 最关键的是所有这些步骤都应该由脚本自动化完成，从导出(check out)代码到将最终产品放在网上供用户下载(当然在开发阶段，产品是放在一台测试服务器上的)。要保证开发过程中的任何东西的任何记录是由文档记录的而不是由某个人的脑子来记录的，这是唯一的办法。否则你会碰到这样的情况，产品需要发布了，可是只有Shaniqua知道如何将产品打包的，可是他刚刚被巴士撞了。在Juno公司(本文作者工作过的公司之一)，要进行每日构建，你唯一需要学会的东西就是双击每日构建服务器桌面上的一个快捷方式。 如果你在发行程序的当天发现了一个小bug，没有问题。修正它，然后重新运行每日构建脚本，现在你可以安安心心的发行程序了。当然，黄金定律是 每日构建脚本应该是把所有的事情从头做一遍，遵循这个定律就不会有什么问题。 将你的编译器的警告参数设到最大(在微软的VC中是-W4 ; 在GCC中是-Wall)，当遇到任何一个最微小的警告时就应该停下来。 如果每日构建失败了，可能整个开发团队的工作会因此进行不下去。当务之急是立刻找出原因，使得每日构建能成功进行下去。某天也许你会一天运行好几次每日构建脚本的。 每日构建一旦失败，应该自动地将失败用email通知整个团队。提取错误日志中的恰当部分并包括在email正文中也不是很难。每日构建脚本也可以将当前的状态报告整理成一个html文件，自动发布到一个所有人都可以访问的web服务器上，这样测试者可以很快知道那个版本的构建是成功的。 当我在微软的excel团队中工作时，我们的一个有效办法是，谁导致每日构建(daily build)失败，他(她)就得负责照看当日的每日构建(译者按:微软通常每日构建都在半夜)，直到有另一个人导致构建失败而接替他(她)。这样做当然可以使每个开发者都小心不要因为自己代码的错误破坏了构建，更重要的是团队中的每个人都可以学会每日构建(daily build)的原理。 如果你的团队在同一个时区工作，在午饭时间进行每日构建(daily build)是个不错的主意。午饭前每个程序员导入(check in)代码，这样当程序员在吃饭时，构建系统在工作。当程序员吃完饭回来时，如果每日构建失败了，所有的人也都在，可以尽快找出失败的原因。当构建系统运作起来时，没有人再会担心别人导入(check in)代码会妨碍自己的工作了。. 如果你的团队同时在两个时区工作，计划好每日构建(daily build)的时间使得一个时区的工作不会影响另一个时区的工作。在Juno公司，纽约程序员在晚上7:00导入(check in)到版本控制服务器。如果他们的导入导致构建失败，印度Hyderabad市(译者按:印度科技重镇)的程序员在纽约时间晚上8:00以后的工作几乎无法进行下去。我们每天进行两次每日构建(daily build)，每次构建的时间都在两地的程序员回家之前，这下就没有问题了。 更进一步的阅读: 一些关于每日构建工具的讨论 做每日构建是很重要的，它是 获得高 质量代码的12个步骤之一。 Windows NT team G. Pascal Zachary 关于微软Windows NT团队每周构建的书中有一些很有趣的东西。超 级明星(译者按:原文为showstopper，指特别受人喜爱，杰出之人 或之物). Steve McConnell(译者按:著名的软件工程作家，Win2000开发组总负责人，其名著《Writing Solid Code》，《Debugging the Development Process》都有中文译本。) 写的关于每日构建(daily build)的文章在这里. 本文最先用英文出版，题为 Daily Builds Are Your Friend 第四战略篇:膨胀软件与80/20的谣传 作者: 周思博 (Joel Spolsky) 译: Bo Yang 编辑: Wenjing Jiang 2001年3月23日 1993年，微软公司的电子 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 格软件Excel 5.0出版了。它是一个巨 大的软件，需要15兆的硬盘空间。当年我们还记得最早上市(1985年左右)的PC硬盘只有20兆，所以15兆显得很多。 等到Excel 2000出版的时候，它竟需要146兆的硬盘空间，几乎增 长到1993年的十倍～微软公司的程序员真是差劲，对不对, 不对。 我敢打赌，你以为我要写一篇令人厌烦的，批评膨胀软件的文章。这种文章因特网上到处都是。批一批，怨一怨，这些庞大臃肿的软件，令我讨厌，还是vi和edlin比Microsoft Word与Emacs强多了，因为前两者很小巧灵活... 哈哈，把你蒙了～我才不会去写一篇那样的文章呢，因为那种说法根本不对。 1993年，根据当时硬盘的价格，Microsoft Excel 5.0占用了$36元的硬盘空间。 2000年，根据当时硬盘的价格，Microsoft Excel 2000占用了$1.03元的硬盘空间。 (这些数字是根据此处的硬盘历史价格数据计算的，以把通货膨胀的效果算进去了。) 从实际经济角度出发，Excel好像变小了～ 说真格的，什么叫膨胀软件,Jargon File把它嘲贬地定义为:“提供最低等的功能，同时占用不成比例的磁盘与内存空间的软件。特别是形容应用软件与操作系统升级来用的。此词在Windows/NT上是常见的，Windows/NT也是它的来源。” 我猜这帮人只不过是恨Windows而已。自从虚拟内存在Windows 386(1989年)上出现后，我已经有十多年没有把内存用完过了。再说硬盘价格已经降到$0.0071元一兆，而且越降越快。 也许Linus ?kerlund能把这个问题解释清楚。他在他的网页 上写道:“这些膨胀软件的一个大缺点，就是即使你只想干一件很小的事，你也要负载这个很大的程序。它把你的内存全用掉了„你不是很有效地利用你的系统。它毫无必要地把你系统的效率弄得很低。” 我明白了，原来它把你的内存都用完了。嗯，不对。自从Windows 1.0在1988年出版以后，操作系统只把用到的代码页放在内存中。如果你有一个15兆的可执行文件，但运行时只用到两兆的代码页，操作系统就只把这两兆从磁盘装入内存中。而且如果你用的是比较现代版的Windows的话，操作系统还会自动调整硬盘，把这两兆代码页放在一起，使程序起动得更快。 我想没有人会否定，在今天强大而便宜的计算机上，起动一个大程序比仅仅五年前起动一个小程序还要快。那么那些人在瞎叫唤什么呢, RA Downes给了我们一个提示。看起来他花了几个钟头，把Microsoft的一个小程序研究了一通，而且因为这个程序有一兆大小，令他十分气愤(他写那篇文章，一兆硬盘只值3.15分)。以他看来，那个程序应该小下去95%才对。可笑的是，他研究的那个程序叫做RegClean，你很可能没听说过。它的作用，是把Windows registry中没用的东西找出来删掉。如果你整天为Windows registry中没用的东西担心的话，你性格上很可能有为事物着迷，难以克制的弱点。所以我怀疑 批判膨胀软件是精神病 的体现，不是软件问题。 实际上讲，膨胀软件的存在是有道理的。最起码的，如果程序员不用担心软件的大小，那么软件就可以早点出版。用户可以早点得到更多的功能。这些功能用时有益，不用时无害。假如你的软件商在出版软件之前，花两个月的时间，把它的软件缩小50%，这对你的实际好处来说，几乎是感觉不到。也许，你的硬盘要是快满了的话，你可以多下载一首MP3歌曲。可是你多花两个月的时间，等新软件出版的损失，你就感觉得到了。而且你的软件商会丢掉两个月的销售额，损失更大。 很多搞软件开发的人，被"80/20"的老规律引诱了。这个规律好像很 有道理:80%的人只用20%的功能。所以你以为，只要实现20%的功能，就能得到80%的销售量。 不幸的是，那从不是同样的20%。每个人都用到不同的功能。再过去十年中，我大概听说过几十家公司，下定决心不互相吸取教训，企图出版“轻形”版本，只有20%的功能的文字处理软件。大多数情况是，他们把软件送到记者哪里去评论，那些记者评论的方法，就是用这个新的文字处理软件去写他们的评论文章。文章写完了，记者就要用到“字数”这个功能了，因为大多数记者写文章时有明确的字数限制。可是“字数”这个功能在软件里却找不到，因为它是属于“没人用的80%”里面。结果记者就会写一篇文章，一方面说着这个“轻形” 软件怎么怎么好，膨胀软件怎么怎么糟，另一方面又说我不能用这个软件，因为它没有“字数”这个功能。而且这种文章 经常有人写。 当你去推销你的“轻形” 软件时，你跟人家说:“嗨，这个软件很小巧，只有一兆。” 人家听了一般都很高兴，然后就会问你有没有对于他们来说很重要的功能，要是没有，就不会买你的软件。 基本概要是:如果你的战略是“80/20”，你就很难卖出你的软件。事实就是这样。这个战略自从软件工业开始时就有，从来没有胜利过。令人吃惊的是，很多倒闭了的公司的高级主管还觉得它是个好的主意。 Jamie Zawinski 在讨论改变世界的首版Netscape时讲得最好:“Mozilla [Netscape 1.0]很大并不是因为里面全是没用的东西(如果真是那样，解释起来倒很方便)。Mozilla很大，是因为你的需要很大。你的需要很大，是因为因特网是个很大的东西。网上有很多小型的浏览器，说起来基本上是没用的。我们当初写Mozilla的时候，从未想把它做成一颗完美无缺的明珠。” 本文最先用英文出版，题为 Strategy Letter IV: Bloatware and the 80/20 Myth 行进中开火 作者: 周思博 (Joel Spolsky) 译: Siyan Li 李思延 编辑: Paul May 梅普華 2002年1月6日 时不时，总有一阵儿，我什么事也干不了。 我也去办公厅，东瞄瞄，西看看，每十秒钟查一次电子邮件，网上逛一圈。也许干点儿象付运通卡账单之类不需要大脑的事。不过要回去哗啦哗啦写程序，可没门儿。 这种不出活的状态，一般通常会持续一两天。在我的软件开发生涯中也有过几个星期干不了活的时候。就像他们说的，我不在状态，我进入不了情况，我找不到组织。 人人都有情绪波动，有的人温和一些，有的响动大点儿，也有的可以整个乱套。但不管怎么着，那段不出活期似乎总是跟忧郁有点儿关系。 我不由得联想到那些专家说，人们基本上控制不了自己吃什么。任何节食计划都长不了。大家总是悠回各自的正常体重。也许作为一个软件工程师，我也不能控制什么时候最能出活。我唯一希望的就是发呆那段能被哗哗干活那段扯平，最终还能混碗饭吃。 自从我干上软件开发这一行起，我平均每天只有两三个的高效时间。这真让我头大。我在微软实习的时候，另外一个实习生告诉我，他每天12点上班，5点下班。5个钟头还包括午餐时间，但他的同事还对他特别满意。因为他干的活比一般人都多。其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的干，还有点不好意思。不过呢，我总是组里出活最多的。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么做不会降低一个小组的生产能力。 每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。 我老想这是怎么回事儿。我努力回忆我出活最多的时候。估计是微软把我搬到一间漂亮的新办公室的时候。舒适豪华的办公室，窗外风景如画，窗对面樱桃花开满了石头堆砌的庭院。所有的一切都那么恰到好处。我马不停蹄地干好好几个月，一口气把Excel Basic的详细设计搞定。用象纪念碑那么高的一叠纸，详细描素了一个超大型目标模型和编程环境，工作之细致，令人难以置信。我自始至终就没停过手。去波士顿参加MacWorld I的时候，我都带着一台手提电脑，坐在哈佛商学院的大阳台上把Windows类别的所有文件都写完了。 按步就班并不难。通常我一天是这样度过的:1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7:30，写到忘记时间。 在以上第8步和第9步之间似乎有点缺陷，因为我不是每次都能顺利 地执行下去。 对我来说，启动是唯一的难题。静止物体在不受外力作用的情况下会保持静止。大脑里有些物质的质量大得不可思议，让它加速太难了。但是只要速度上去了，在全速行使的情况下，倒不用使什么劲就能继续走下去。就象骑着自行车去作一次自费横穿美国的旅行，一开始，你根本想象不出要花那么多时间让车轮动起来，可是一旦动起来了，让它们继续转就不是一件很难的事了。 也许高效率的关键就:启动起来。配对编程法之所以成功，说不定就靠两个人在一起，互相强迫对方启动起来。 我在以色烈当伞兵时，一次，有个将军来给我们讲实战战术。他告诉我们，步兵战术其实只有一种:行进中开火。你一边开火一边朝着敌人冲过去，火力让敌人抬不起头来，不能朝你开火 (当一个军人喊:“掩护我”的时候，他的意思就是“在我冲过街时候，你朝敌人猛烈开火，迫使他猫起来，没法朝我开火)。前进了，你就可以占领阵地，接近敌人，这样你的胜算要大的多。你要是不往前冲，敌人就有时间来搞清楚形势，这可不妙。你要是不开火，敌人就要朝你开火，撂倒你。 我很长一段时间都在想着这个教导。我想通了不论是战斗机空中格斗还是大规模舰队攻击，大部份军事战略战术都是以行进中开火作为基础的。我又化了十五年时间才想通了行进中开火也是一个人在现实生活中成功的基本原则。你每天都得往前进点儿，不用想你写的程序怎么差劲，怎么卖不出去，只要你不停地写，不停地改，滴水也能穿石。同时， 要注意你的竞争对手朝你开火。他们是不是想让你全心全意应付他们的扫射，好让你往前走不了呢, 想想这些年来，微软开发出来的资料存取方法，从OBDC，RDO，DAO，ADO，OLEDB直到现在的 ADO，.NET，不停翻新，技术上有必要吗, 还是因为那个设计组实在蹩脚，每过他妈一年就得重新发明一遍资料存取技术,(实际上可能真是)。它最终的效果其实是一道掩护火力，让竞争者别无选择，只能把本来该用来开发新功能的宝贵时间都用来移植和升级了。仔细看看软件行业，干得好的公司对那些对大公司都依赖最少，不用把所有精力都用来为赶潮流而把程序重写一遍，还得修改那些只有在Windows XP上才会出现的缺陷。那些花太多时间去猜测微软未来发展方向的公司，日子都好过不了。有些人见了.NET就发怵，忍不住要按.NET来完全重建自己的体系结构，以为自己别无选择。哥门儿，看清楚了，微软是在朝你开火呢，而且这只是掩护火力。这游戏就是这么玩儿的。这样一来，他们就可以大步朝前走，而你却不能。你要支持Hailstorm 吗,SOAP呢,还有RDF,是因为你的顾客需要，所以你支持它们,还是因为有人朝你开火而你觉得应该还击,大公司的营销部都懂火力掩护。他们到客人那儿就说，“你们不一定非买我们的。谁的产品最好您就应该买谁的。不过，我们想提醒您，在下单之前最好先确认他们支持(XML/ SOAP/CDE/J2EE)。否则你们就会被他们的技术套牢。”。等到小公司去向这个客户推销的时候，那个听话的CTO就会问他们:“你们有J2EE吗,”。他们回去就只好不管卖不卖得掉，都埋头打造他们的J2EE。他们也就再没有机会来展示自己的特色了。其实，这只不过是个打勾功能。因为有个打勾拦在那儿空着，你就必须有这个功能。其实谁都不需要它。这就是火力掩护。 对于我这样的小公司来说，行进中开火意味着两件事。别跟时间过不去，同时你还得每天都进步。天不负苦心人，你终有出头的一天。我昨天花了一天时间只不过让FogBUGZ的颜色稍微好看点。这不要紧，只要不停步。最重要的是，我们的软件越来越好，客人越来越多。在我们达到Oracle 的规模之前，我们并不需要通盘战略。我们只需要每天早晨到办公室来，别多想，打开编程器。 本文最先用英文出版，题为 Fire and Motion 看起来简单， 实际上复杂 作者: 周思博 (Joel Spolsky) 译: Bo Yang 翻译 编辑: Billy Chen 编校 2002年3月4日 我们在CityDesk里有一个使用性上的小问题。 问题是这样的:你可以用菜单上“导入网页”的命令，从因特网上导入一个文件。你也可以用鼠标拖放的方法，从磁盘上导入一个文件。但是菜单上没有“导入磁盘文件”这个命令，所以有些用户没有发现CityDesk 有这个功能，或者他们试图用“导入网页”这个命令去导入磁盘上的文件，结果造成无法成功导入。 我一开始想这个问题很好解决，大概的方法就是用一个两个页面的文件导入向导。第一页问你:“你要从哪里导入,”。如果你选择“磁 盘”，第二页就会提示你选一个文件;你要是选择“因特网”，第二页就会提示你输入一个URL. 我差点就开始动手去实现我这个想法了，但是有些事情使得我并没有这样做。我决定先写一个小的规约再说。写出来的规约如下: 第一页 你要从哪里导入, 磁盘/因特网 第二页(磁盘) 标准的打开文件对话框 第二页(因特网) 用小浏览器让你输入一个URL 突然间我想到一个问题。Windows的打开文件的对话框，通常是由操作系统提供的。能不能把这个对话框放到我的文件导入向导里面呢, 嗯„ 我查了一下。是可以这样做的，但这不是一件好玩的事，而且要花好几个小时的时间。我能不能不使用导入向导的方式呢,我重写了一下我的规约: 两个菜单项: 1)从网上导入网