2002年的Bug A与2008年的Bug B同时穿越到2013年，并在某个场合相遇了。

上周六，项目组本应以一个愉快的心情结束一天的工作的，但一个2002年的Bug A与另外一个2008年的Bug B同时穿越时空来到了2013年，并且恰恰在那时那刻（下班前）相遇了，于是项目组由放松变成了忙碌，由愉快变成了紧张，17：30的下班点也因此延迟到了凌晨1：30。

Bug A来源于2002年我们发布给客户的一版客户端API，严格来说称其为Bug不免有些冤，它只是遇到Bug B时才会被触发，其只是在处理机制上缺少一些容错的考虑罢了。Bug B才是名副其实的Bug，居然明目张胆地违反协议，擅自在登录应答包的Body尾部补了一个字节的“脏数据“，导致使用我们客户端API的某企业短信通知系统出现故障。

关于这次的“故障”，我想感慨的不是这次的Bug有多么的诡异难找，而是下面这几点：

* 生产环境中场景的复杂性与多样性

任你用例再多，测试人员经验再丰富，脑力再强大，也很难设想出如此之情形。往往我们在模拟环境中测试的都很好，开发和测试人员都手拍胸脯保证说：“没问题了”。但一到生产环境中，问题就像滚雪球一样越来越多，弄得大家焦头烂额。究其源头还是在开发人员这里，开发人员是第一责任人。已经离职的制造出这两个Bug的“前辈们“肯定不会想到，他们的Bug居然穿越到2013年相遇了，否则我相信他们在当时一定会认真对待代码的。

* Bug是藏不住的

通过此例可以让我们看到：Bug终有一天是会暴露的，是藏不住的。这“潜伏”了10多年的问题不也在这次事件中暴露出来了吗。所以说我们写代码的时候，一定要心中有“追求0bug”的理想和目标，严格要求自己和自己的代码，采用各种手段，如代码评审、单元测试、持续集成、自动化的模拟环境验收测试等对所写代码进行“残酷”的打磨和考验，让Bug遛到生产环境的机会尽可能地小。

* 版本的变更管理有漏洞

这又是一次在产品升级后导致的“故障”，原因在于没能完整的识别出这次升级带来的所有软件变更。其少引发Bug B的那行代码的“作用”没能识别出来。这的确是个难题，如果不是原开发人员或评审人员“自发”上报此处的变更，这个变更太容易淹没在代码海洋中而丢失了。目前似乎也没有太好的办法。如果未来能有一种自动识别版本间代码不同且能识别出差异代码的语义变更的工具，那么我相信这款工具一定大卖。 

近期产品线出现这样一个“怪现象”：许多已经完成编码并具备提交给测试组的版本没有测试人员对应。测试部那边给出的策略是：按版本优先级从高到低依次测 试。这样一来一些重要版本需要到3个月甚至更长时间之后才能开始测试。可以肯定这种现象是生产环节的一个问题，但用什么理论去解释和分析这个问题呢？我想 到了“库存” – 软件库存。

《Joel说软件》的那个Joel曾写过一篇名为《软件库存》的文章，也正是看了那篇文章后，我才第一次了解到软件库存这个概念。库存似乎是传统制造业中 的一个概念，但软件开发其实也是广义产品生产的一种，虽然有其特殊性，因此有些产品制造方面的理论是可以应用于软件生产过程中的，软件库存就是其中之一。

传统制造业的库存较为容易理解，零件、原材料、半成品以及未卖出去的最终产品这些都可以理解为库存。而软件生产中的库存都包含哪些内容和环节呢？一旦形成库存，利弊又有哪些呢？

* 未纳入开发的需求/特性

这里所说的需求/特性是经过决策后将来要开发的且能带来价值的，而不是为了大而全而滥芋充数的那种。这类需求/特性可理解为已经采购并存放在库中尚未投入 生产的原料库存。这类库存如果变得很大，则很可能说明产品市场场景甚好，但也可能是现有的生产能力出现了不足；如果这块库存过小或没有，则会导致后期开工 不足，或者说产品的持续成长前景黯淡，市场对其的需求也不乐观了，组织对此情况应做出迅速反应。

* 已经开发完毕但未经测试的半成品

开发人员开始投入，根据需求/特性疯狂编码、单元测试，生产出未经专业测试的半成品。这些半成品因其中潜在的许多缺陷而不能作为最终商品投放市场，因此无 法收回成本并赚取利润。一旦这个环节形成库存，则说明后续质量验证环节的生产能力与软件开发环节的生产能力出现了不匹配，这将导致版本中的问题不能尽快地 暴露，使得问题流向其他版本或其他系统中，直到测试开始后才能发现，后续要花费更多的工作量做关联的修正。这也是我所在产品线所遇到的棘手问题，唯一的方 法就是提高质量验证环节的生产能力，至于如何提高，因地制宜，这里不表。而较小的库存或这个环节无库存，也会导致后续质量验证环节的开工不足，或衔接出现 节奏性的问题。

* 未上市或未卖出的成品

当产品顺利通过质量检测部门的测试后，便可正式发布，变成最终产品- 成品，交付到最终用户那里。但如果这个环节出现库存，问题将变得严重得多。要么是前期市场估计过于乐观，要么是行销人员不给力，要么则是生产过剩，没有做 好库存管理等等。如果这个环节库存过小，则最终客户依旧无法及时得到产品，不利于保持客户粘性，客户很可能退而求其次，选择其他厂商的产品了。

以上简要分析既提到了不能忽视库存的存在，也说到了无库存的危害。传统制造行业一直在追求着一种“零库存”的概念，所谓“零库存”，是指物料（包括原材 料、半成品和产成品等） 在采购、生产、销售、配送等一个或几个经营环节中，不以仓库存储的形式存在，而均是处于周转的状态。它并不是指以仓库储存形式的某种或某 些物品的储存数量真正为零，而是通过实施特定的库存控制策略，实现库存量的最小化。在软件生产领域也可借鉴这一概念，在各个环节努力维持合理且适当的库 存，这对整个生产过程是大有裨益的。

可以看出“零库存”的一个精要就是及时收回产品的投资，获得利润，保持生产过程的持续有效进行。这让我想到了当今软件过程的演化：从最初的瀑布过程到目前 流行的迭代和敏捷等过程，以及流行的持续交付等概念，它们似乎都是在追求“零库存”，追求快速回流价值。或者说库存理论潜在地催生了敏捷、持续交付等概念 的迅速发展，并让人们看到其中的裨益所在。