不愿做不必要的工作是程序员的一大美德。

和其它耗在软件开发的花费比起来，时间无疑是最宝贵和最有价值的: 所以相应地，该耗费在解决新问题，而不是对那些已存在确切解决方案的问题老调重弹。这种态度对于开发投入来说，无论是在人员资本的“软”含义，还是在投资经济收益的“硬”含义都可以收到最好的回报。

重新发明轮子之所以糟糕不仅因为浪费时间，还因为它浪费的时间往往是平方级。走捷径往往产生粗糙、未经思考的版本，长期而言这是假性节约，但通过这种方式来节省重新发明时间的诱惑几乎总是无法抵抗的。
–Henry Spencer

Unix 的经验是，养成良好的习惯，尝试通过最少的新发明，组合现有组件以形成原型，而非匆忙地编写独立的、只能使用一次的代码。

#16.1 猪小兵的故事

猪小兵的故事

#16.2 透明性是重用的关键

猪小兵的多数麻烦（也意味着大规模质量问题）归根结底是透明性一一或者更确切地说，是缺乏透明性。

无法修正不通内情的东西。实际上，任何具有非平凡 API 的软件如果无法深入肌理，都无法被正确的使用。

只有文档，不仅在实践上不足，在原则上同样不够：文档并不能传达代码具现的所有细微差别之处。

有了源码，可以装备程序来进行衡测，可以通过编译来进行调试，这样在晦涩模糊的情况下就更容易探询程序的行为。而如果需要改变程序的行为，当然也可以做到。

需要源码还有另外一个重要的原因。Unix 程序员在几十年中学到了“只有变化才是永恒”，的经验，而源码是可以永续的。

源码是必需的，因为即使不想或不需要改动软件，可能还得在新的环境中重新编译以保证它能继续运行。

透明性的重要，以及代码遗留问题，是要求重用代码开源以供检验和修改的两个理由。

#16.3 从重用到开源

软件开发者希望他们使用的代码是透明的。更进一步，他们在换工作时不希望失去他们的工具包以及他们的专有经验。他们厌倦了成为受害者，腻烦了被生硬的工具和知识产权壁垒弄得灰心丧气，受够了不断地重新发明轮子。

这些就是开放源码的动力，从猪小兵痛苦的初步重用经历中产生的动力。这其中涉及了自我意识，设计最好的实践需要情感的投入，而不是冷漠无聊的过程。软件开发者同其它任何类型的工匠和技师一样;他们想要成为艺术家，这并不是什么私密。他们有艺术家的动力和需求，也有拥有听众的欲望。他们不仅仅希望重用代码，他们也希望自己的代码得到重用。这种势在必行的意念驱动，超越和颠覆了任何短期经济目标的达成，也不是闭源软件生产所能够满足的。

#16.4 生命中最美好的就是“开放”

来自 Unix 世界以外的人们（特别是非技术人员）往往倾向于认为开源（或“自由”）软件必然比商业软件差，是假冒伪劣的，不可靠的，带来的麻烦只会比所能免除的更多。

#为什么开源软件很可能产出质量特别高的软件

但这遗漏了重要一点：一般来说，编写开源软件的人都很在乎它，也需要它，自己使用而且通过发布这个软件在同行中赢得个人声誉。他们的时间也往往更少地耗费在会议、反馈设计更改或是各种官僚的开销中。他们也因此具有更强的动力和更好的立场来完成卓越的工作，远远超过那些薪水的奴隶。

开源用户社区（那些同行）不会羞于抓 bug，而且他们的标准很高。发布不够格软件的作者会承受许多的社会压力来修正或撤回代码，如果需要的话还能得到许多专家级的帮助。结果，成熟的开源软件包一般都是高质量的而且常常在功能上比任何专有等价物都要高级。这些开源软件或许看起来并不漂亮，想看懂文档或许也不容易，但其至关重要的部分通常都会工作得相当漂亮。

在同行评审效应之外，另外一个可以推测出质量上佳的理由是：在开源世界的开发者，从来不会受最终期限的压迫，不会一闭眼、一拍脑门就发布软件。因此开源实践同其余地方的一个区别就是，1.0 级别的版本实际上意味着软件可以使用了。事实上，0.90 或者更高的的版本号就相当可靠，表明代码已经是成品了，但是开发者还是不敢拿这个软件来赌自己的声誉。

#如何评价一个开源软件是否可靠

评估开源软件包的方法是阅读其文档和快速浏览它的部分代码。如果所见的代码编写恰当，文档完备，那么鼓励使用。如果能够证明软件包已经有些年头并且存在实质具体的用户反馈，就可以断定它是相当可靠的（无论如何还是测测为佳）。

在 README 文件以及项目新闻或源码发布历史文件中，所提到的除原作者之外的人数，是度量成熟度以及用户反馈量大小的好方法。很多人呈报修正和补丁本身就是良好的表征，既表明存在一个相当重要的用户群保持着对软件作者的敦促和警醒，也表明软件维护者是恪守职责的，能够对反馈作出响应并订正错误。当然，这也是一个暗示，如果早先的代码是充满 bug 的雷区，不用等到最近的爆炸，早就有受惊的人群踩得响噼里啪啦的了。

#16.6 使用开源软件的问题

文档通常是个更严重的问题，许多高质量的开源软件包的应用范围和它们在技术上的领先不相协调，就是因为它们的文档很糟糕。Unix 传统鼓励了太过专门的文档风格，这种风格（尽管或许会在技术上涵盖软件包所有的功能特征）往往假设其阅读者也相当熟悉应用程序的定义域，并且阅读得非常仔细。