这个故事是我最近在领英Multics论坛上发布的一条消息的编辑版本。
让你的修改快速“上线”可能成为强大的激励。这是关于我首次在Multics系统中引入漏洞的故事——该系统是麻省理工学院在1960年代末至1970年代初开发的一款重要操作系统。
我当时是麻省理工学院的一名新生，刚被录取加入Multics项目组。我自愿为dprint（"守护进程打印"）命令添加新功能，该命令负责将请求排队交由行式打印机守护进程处理。一位经理要求我记录请求中的复印份数，而不是直接向队列添加N个请求。这个改动能解决涉及已完成打印请求删除的竞争条件问题。我完成修改后进行了测试，结果令人满意。
我的修改很快被部署，获准改进系统令我欣喜若狂。但这份喜悦转瞬即逝——刚接起办公室电话，就听见用户怒气冲冲地抱怨我的修改搞砸了他的程序。我立即返回检查，才发现自己竟未注意到同源文件中子程序的入口点，更未进行测试。果不其然，我确实搞砸了。 修复后生活如常。但那通电话我至今难忘。虽然我仍非完美之人，但多年来那个愤怒的声音在我脑海中回响，让我避免了许多类似的粗心失误。
我从这个案例中总结出的箴言是：“未经测试的代码不会工作。”
测试你的代码。自己找出错误，别让别人来发现。避免听到愤怒的质问！