# 十二、软件开发中的5个世界 有一件重要的事几乎在所有程序设计和软件开发文献里都没提到,所以我们之间有时会有误 解。 你是个软件开发者,我也是。不过我们的目标和需要可能并不相同。事实上软件开发有几个 不同的世界,而且每个世界的规则都不一样。 去找一本关于UML模型的书来看看,里头完全不会提到UML不适合用于驱动程序。或者你去读 另一篇说「20MB执行时期链接库[.NET要用的]并不是问题”的文章,它也并没有指出明显的 事实:如果在只有32KB ROM的呼叫器上写程序,这绝对是个问题! 我认为这里头有五个世界,虽然偶而有重迭但通常都不会。这五个分别是: 1. 热缩封膜(Shrinkwrap)软件 2. 内部用的软件 3. 嵌入式软件 4. 游戏软件 5. 用后即丢的软件 当你读最新的极限程序设计书藉或Steve McConnell最好的书,或是Joel on Software或软 件开发杂志,会看到很多有关如何开发软件的声明,不过几乎都不会提到所讨论的开发类型, 这实在是很不恰当,因为有时候世界不同,做事的方法也会跟着变。 让我简短的介绍这些类型。 热缩封膜软件是「外头」很多很多人要用的软件。可能是用玻璃纸封好在CompUSA贩卖,也 可能是透过Internet下载的。可以是商业软件或共享件,也可以是开放源码或GNU或其他型 式-重点是该软件会被成千甚至数百万人安装使用。 热缩封膜软件由于两个特性而衍生出特有的问题: 1. 由于使用者很多而且通常都有代替商品,所以用户接口必须比一般水平更容易才会成功。 2. 由于软件会在很多的计算机上执行,所以程序对计算机间的差异要格外有弹性。 上星期某人寄了一封电邮给我,内容是CityDesk—个只在波兰版Windows出现的问题,原因 是那个操作系统会用右边的ALT键输入特殊字符。我们测过Windows 95、95OSR2、98、98SE、Me、NT 4.0、Win 2000还有Win XP。也测过安装了 IE 5.01、5.5或6.0的状况。我们也测了 美国、西班牙、法国、希伯来文、和中文各种语文的Windows。可是就是还没测到波兰版。 热缩封膜软件有三个主要的分支。开放源码软件通常是不支薪的人开发的,而这些人的动力 经常会剧烈变动。举例来说,在全都是志愿者的团体中,被认为不「好玩」的事通常没人会 做。另外也如Matthew Thomas所指出会降低可使用性。开发动作很可能是分散在各地进行, 导致团队沟通的质量参差不齐。在开放源码世界很少会面对面在白板旁一边画着框框和箭头 一边讨论,所以这类项目在需要画图沟通的设计决策上通常都做得很差。因此这种地域分散 团队在复制现有软件时做得会好很多,因为抄现有的软件就不太需要设计了。 顾问软件是另一种热缩封膜软件分支,由于需要很大量的客制化和安装,所以得用恐怖的价 钱请一整批顾问来安装。客户关系管理(CRM)和内容管理系统(CMS)软件通常都属于这一类。 有些人会觉得这些软件其实什么事都做不了,只不过是找一群顾问进来每小时付300美元的 借口罢了。虽然顾问软件装得像热缩封膜软件,不过由于安装启用的成本太高,其实比较像内部用的软件。 像Salesforce.com或eBay之类的Web商业软件还是必须容易使用并能在很多浏览器上执行。 虽然开发者比较幸运,能或多或少控制所部署的环境(位于数据中心的计算机),不过还是得 处理各种浏览器间广泛的差异,以及大量的使用者。因此我认为它基本上算是热缩封膜软件 的一支。 内部用软件只考虑一种状况,在一家公司的计算机能跑就好了,因此开发起来容易多了。你 可以对执行环境做各种的假设。你可以要求某个版本的Internet Explorer或微软Office或 Windows。如果你需要幽图表,呼叫Excel来幽就好了;我们部门里每个人都有Excel。(不过 在热缩封膜软件这样做的话,潜在客户大概会跑掉一半。) 在这里可使用度并不重要,因为必须使用的人数有限,反正也没有其他选择就只能将就。开 发速度会更加重要。由于开发投入的价值只局限于一家公司,能用的资源相对上也少了许多。 微软花得起五亿美元开发一套对一般人只值80美元的操作系统。不过当Detroit Edison(译 注:能源公司)开发一个能源交易平台时,投入的成本就必须适合单一家公司。要得到合理 的投资报酬率就不能像热缩封膜软件一样花钱。所以很悲哀的,很多内部用软件都烂到不能 再烂。 嵌入式软件具备一个特性,它会被放在硬件里而且几乎都不能更新。这可是个完全不同的世 界。由于没有第二次机会,质量要求比平常高出许多。你可能得用一颗比一般桌上型处理器 慢上许多处理器,所以得花很多时间做优化。程序漂不漂亮没关系,跑得快才重要。可用的 输入及输出装置可能也很少。 上周租的车上有装全球定位系统(GPS),不过上面的输入/输出很差,几乎不能用。你曾试过 用这种玩意输入地址吗?他们在屏幕上画了一个「键盘」,你必须用箭头键从五个小矩阵(每 个里面各有9个字母)选出要的字母。(我自己车上的GPS有触控屏幕,使用接口就好很多多。 不过离题了。) 把游戏软件独立算一类有两个原因。首先游戏开发的经济是打击导向的。有些游戏击出安打, 更多的游戏被三振,如果你想在游戏业赚钱就得了解这一点,然后确定你有多个游戏,才能 用大赚的钱去平衡失败的损失。这其实比较像电影业而不是软件业。 游戏开发更大的问题是只能有一个版本。当使用者玩完毁灭公爵3D版本,并不会因为修正了 某些问题或増加新武器而升级成毁灭公爵3.1D。除了少数例外,一般玩完一个游戏后再重玩 是很无聊的。所以游戏的质量要求和嵌入式软件相当,又要有足够的钱一次就把东西做好。 热缩封膜软件开发者就幸福多了,如果1.0版不符合大家的需求,再出个2.0版或许就可以了。 最后用后即丢软件是只为了得到其他东西而暂时创造的软件,当你达到目的之后永远都不会 再用到。举例来说,你可能会为了其他需要,写一个小命令脚本把某个输入档案转成需要的 格式,这就是只用一次的操作。 或许还有其他我忘记的软件开发类型。 这里要讲一件重要的事情。当你阅读那些由专业软件开发大师或顾问撰写的程序设计方法书 时,可以放心认定书里说的都是企业内部用的软件开发。不是热缩封膜软件,不是嵌入式软 件当然也不会是游戏软件。为什么呢?因为这些大师都是企业在请的,是企业在付他们的薪 水。(相信我吧,id software是不会请Ed Yourdon去教结构化分析的。) 上星期Kent Beck声称如果实施极限程序设计的话,就不需要错误追踪系统。因为成对程序 设计(持续进行程序代码检视)和测试导向开发(保证100%的自动测试涵盖率)的结合,让你几 乎不会出现问题。这我可就听不懂了。于是就到我们自己Fog Creek的错误追踪数据库里看 看究竟都是在忙些什么问题。 瞧,我发现这些问题绝少能被成对程序设计或测试导向开发找出。我们很多的「问题」基本 上就是XP所谓的story,只是功能要求。我们用问题追踪数据库来记录要实作的大小功能和 改善,并且用它来管理这些工作并排定优先级。 其他很多问题都是只会在外头经过大量使用后再会发现。比如波兰键盘的问题。这种东西成 对程序设计是不可能发现的。还有那么我们未曾发生,把不同功能一起运作时才出现的逻辑 错误。程序愈大愈复杂,功能间的未考虑到的互动就会愈多。一个很少出现的特别字符序列 (`{${?`,如果你一定要知道的话)让字汇分析器错乱了。有些ftp服务器在删除不存在的档案 时会出错(我们的ftp服务器不会有事,所以我们从来没遇到过。) 我很小心的看过每一个问题。在CityDesk更新版所修正的106个问题中,只有5个可以藉由搭 挡程序设计或测试导向设计来预防。事实上我们知道而且觉得没关系(这只能让我们的客户 来指正!)的问题远比XP方法能抓到的要多。 不过就其他开发类型来说Kent是对的。就大部份的企业开发应用而言,上面这些东西都不算 问题。输入不合法时程序会当掉?重新执行一次,这次注意不要输入{${?了!另外我们只有 一种FTP服务器而且全公司都没有人在用波兰版的Windows。 不管在做什么项目,大部份软件开发的事情都是一样的,不过并不是每件事都是。当某 人告诉你某个方法并认为可以用于你正在做的工作时。先想想这个家伙是打哪来的。Steve McConnell、SteveMaguire还有我都来自相同的小角落:一个在华盛顿州雷蒙撰写客户众多 的电子表格应用程序的世界。因此我们对容易使用有很高的要求,同时要求问题的数目要少。 其他方法论大师的工作是企业内部开发的顾问,所以他们会说那些话。不管如何,我们都应 该能由对方身上学到一些东西。