查字典图书网
查字典图书网
软件工程比任何其他工程学科都更需要返工，因为软件涉及到抽象概念。如果准确描述硬件都会有困难的话，那可以想象一下人们形容那些只存在于脑海里的想法或芯片中电流的传导模式该是多么困难。我一下就想到了一句格言：“入此门者，莫存希望”（Abandon all hope, all ye who enter here）。 如果最终用户可以详细阐明其想要的功能，如果软件工程师能够完全了解用户现在和未来的需求，那我们可能就不需要软件了。每个编写出来的程序可以第一时间就被烧录到只读存储器（ROM）里。遗憾的是，这种完美的世界并不存在。 在早期做软件设计师的日子里，我常常会追求软件的完美。我反复修改子程序，直到它们能够最快速地运行，代码也足够干净整洁；我还重复审阅程序，希望能找出哪怕一丁点的改进之处；在想到任何新点子的时候，我都会去添加新的功能（是的，我就是传说中的“功能控”）。我尽情发挥，直到老板将我拽回到现实。 “该发布软件了。”他宣布。 “可是我还没有干完呢！再多给我几天时间吧……” “永远都没有做完的软件，只有发布的软件。” 在软件发布之后，没有人真正知道会发生什么。经验丰富的工程师可能会有一些模糊概念，大概知道软件面对的客户群，它会被应用于什么样的环境之下，等等。但他们很难预料这款软件产品最终的命运到底是成功还是 失败。 我一度在一家大型电脑公司担任电话技术支持工程师。在干过多年操作系统的设计工作之后，我转换成了一个与以往截然不同的角色，开始为我们编写的程序作客户支持。这段工作经历确实让我眼界大开。从事软件设计工作时，你其实很容易掉入一个怪圈，认为一切尽在自己的掌握，误以为自己很了解人们会如何使用你的软件。 你错了。也许你确实对此信心十足。但是，安然待在办公室工作间的工程师，身边围绕的同事与自己一样同样拥有高学历，他能意识得到下列诸多情况吗？ 某个在交易日导致系统反复崩溃的内核bug可能会给一家华尔街企业造成每小时100多万美元经济损失。一个星期之后，该公司在心烦意乱的情况下选择安装原系统竞争对手的产品。可再过了一个月，他们还是重新切换成最早的系统，因为尽管它有一些缺陷，但在这两个系统之间，还是原来的系统显得更为可靠。 一家石油公司可能会使用某个系统来对墨西哥湾进行地震波扫描以寻找天然的石油储备。他们每天都会获取到千兆字节数据，这需要在系统集群上安装90多块大硬盘。人们必须能够随时获取所有数据。而且出于安全考量，没有任何一名地质学家能够持有访问所有关键数据的密钥，这是因为公司很担心会有人带着在哪开采石油的机密信息跑掉，这将会给公司造成数十亿美元的损失。 一家每天在数据库中存储超过1000万条记录的电信公司想设计一个新系统，让它每天可以插入1亿条记录。每秒处理1000次数据库的插入动作本身就已经够困难的了，可现在，他们不得不在高峰期处理每秒高达5000次的数据插入工作。 某家电力公司的系统是美国最大一个州的电网中央控制器。一旦该系统出现故障，就可能导致百万人断电。 Unix的开发人员当然不知道Unix上会发生什么事情。MS-DOS、OpenVMS和一切其他操作系统的开发人员也一样。每一个新的操作系统（Linux也不例外）都会将它们的设计者带到未知领域。他们唯一的希望就是不断收集系统使用报告，然后纠正过程中的相应偏差。 例如，Ken Thompson在编写第一个Unix内核时，有没有注意到可移植性的重要性呢？显然没有，因为他使用的是汇编语言。后来，他采取了一门高级语言对它进行了改写，也改变了原来的方向。那么， Dennis Ritchie是否预料到了C语言将成为一门通用编程语言，让数百万的程序员为之爱恨交加呢？也没有。他那本经典著作The C Programming Language 的修订版包括了对该语言规范的修订，这更加让我们确信他在第一次创作的时候并没有将它完全折腾好。 因此，我们大多数人都还在学习。即使我们自负到认为自己知晓一切，也总会有人改变对我们的期望。那我们到底该如何开发软件呢？接下来的这条原则是关键。