解决方法

设计并构建一套玩具系统，此系统从使用的工具集上（而不是功能范围上）与你在工作中构建的系统类似。通过这种方式为失败做出预算。

如果来自失败的经验可以与来自成功的经验一样多，那么你需要一个相对私有的空间来寻求失败。在抛球杂技中，抛三只球的表演者，如果从来没抛过五只球，那他就永远不会取得进步。而那些连续几个小时去拣落下的球直到拣得背疼的人，最终却能把技艺练好。同样的经验也适用于软件领域。正如抛三只球的表演者不会在正式的表演中抛五只球，软件开发者也需要一个安全的地方来犯错误。

Steve Baker是一位在加拿大新斯科舍（Nova Scotia）省工作的青年，在那个不大的软件开发机构中，他担任主管和专家。Steve曾讲述过这样的期望如何影响了他：“每个人都期待我已经知道了解决问题的正确方法。既然不能通过那些项目来获取经验，我不得不停止学习。”这与Ade的咨询经验类似，在咨询当中，他也犯不起错误，并且不能从那些依赖他永远正确的人的身边走开。Ade知道，为了学习他需要有允许球落下的自由。跟他所面对的无数软件开发者一样，Ade通过“质脆玩具”来帮助自己学习。

在实施“质脆玩具”模式时，要让玩具系统跟你的学徒生活相关而且有用。比如，构建自己的wiki、日程表或者地址簿。针对要解决的问题，你的方案可以是过度工程化了的，而且很可能有一种现成的东西可以轻易取代它。然而，这些项目是允许你犯错的。在这些项目中，你可以尝试那些可能导致灾难性失败的思想和技术。但这些失败只可能伤害到一个人，那就是你。

运用这一模式的经典例子就是那许许多多构建了个人wiki的人。对学徒来说，个人wiki是个了不起的工具，因为你可以用它来“记录所学”。Wiki可以成为很好的“质脆玩具”，因为它们可以很简单^[1]，而且你可以参考“使用源码”这一模式，去找出无数的例子来看。随着时间过去，维护一个wiki可以教会你关于HTTP、REST^[2]、文本解析、Web设计、缓存、全文搜索、数据库和并行等各种技术。如果维护它的时间足够长，当你最终增加了一种特性，需要改用不同的存储格式却不想丢弃所有数据时，它还能教你有关数据迁移的技术。

“质脆玩具”模式的其他例子包括像Tetris和Tic-Tac-Toe这样的游戏（我们的一位前同事有一种习惯：每学习一门新语言，就用它来编一个游戏）、博客软件和IRC客户端。问题的本质在于构建玩具包含了对新事物的学习，而且提供机会让你在特殊的环境中加深对手中工具的理解，这个环境不仅安全（因为你是唯一或者最重要的用户），而且，即使跟最强大的商业产品比起来，你仍有余地来更好地服务自己作为一名用户的需求。

这些就是你的“质脆玩具”。当你带着它们从一份工作转向另一份工作，其中的某一些将成为自身技能的生动体现。尽管如此，你还是要记住：它们只是玩具，而且正因为这一点它们应该是有趣的。如果它们没什么意思，那么当最初的热乎劲过去之后，它们将成为尘封的旧物，而你则将自己的精力关注到你真正乐于构建的东西上去了。

这类玩具经常都是些工业级工具的简单再实现，重新实现它们可让你更深入地理解哪些因素导致了这种工具的现有设计。甚至会有这种可能：你的某个玩具获得了自己的生命，并拥有了其他用户。在那种情况下，你最后将不得不寻找一个新的质脆玩具。

[1]最短Wiki竞赛：http://c2.com/cgi/wiki?ShortestWikiContest。

[2]Representational State Transfer，针对万维网这样的分布式超媒体系统提出的一种软件架构风格。