# 十二、软件开发中的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还有我都来自相同的小角落：一个在华盛顿州雷蒙撰写客户众多 的电子表格应用程序的世界。因此我们对容易使用有很高的要求，同时要求问题的数目要少。 其他方法论大师的工作是企业内部开发的顾问，所以他们会说那些话。不管如何，我们都应 该能由对方身上学到一些东西。