下做好依赖管理的十五条准则

但这也不是绝对，有些代码确实算是「完成」了。
譬如 NPM 的包--，很早就有了，但基本不需要再修改了。
5、被使用的次数
依赖包管理器平台通常可提供使用情况的统计数据，或者你可以去搜索引擎搜索来判断是否很多人用此包。很多人用的话，至少说明这份代码能满足这些人的使用，并通常能快速发现新问题。
广泛的使用量，其实也为持续维护提供保障，因为若维护者不维护了，还会有其他有兴趣的人去接手维护。
举例来说，像PCRE、Boost、JUnit这些库被极为广泛地使用着。在你碰到问题前，很可能别人已经碰到，且已经修复了。
6、安全性
举例来说，2006 年代码搜索系统，用了grep而非开源的代码。当时流行的PCRE正则表达式库似乎是一个不错的选择。
但的安全团队说，PCRE有一系列的问题包括缓冲区溢出（特别是其解释器中）。
在 NVD 中也能找到关于PCRE的相关问题。
但是，代码搜索系统并没放弃使用PCRE，而是更谨慎的进行测试和问题隔离。
7、查看许可证
上，有一部分代码库没有明确标明许可证。
然而，此时此刻允许，并不表示你的项目或公司能一直可以使用这些依赖。
譬如，就不允许使用基于类似这几种许可证的代码：AGPL（容易有法律风险）、WTFPL（过于模糊）。
8、检查一下依赖包的依赖
间接依赖中的问题与直接依赖中的问题都是一样的。依赖包管理器平台可以列出包的所有依赖情况，所以理想情况下，你应逐一进行检查。间接的依赖也可能会导致风险，一个包自身的依赖需要更多的检查工作。
很多开发者从来不检查代码的间接依赖，也不知道间接依赖了什么。
例如，2016 年 03 月，NPM 社区发现许多广泛使用的项目（如 Babel、Ember、React）都间接依赖了一个很小的库letf-pad（1 个只有 8 行的函数）。而left-pad的作者从 NPM 上删除了这个包，这导致很多 Node.js 用户的项目构建失败，甚至连left-pad自己也不例外。
例如，NPM 上总共约 750,000 个包，其中 30% 直接或间接依赖于-- 。根据（图灵奖得主）对分布式系统的观测，依赖包管理器平台可以轻松让一个包失效，从而导致你的包莫名变得不能用，例如无法编译构建打包。
9、通过自己的测试来检查
如前所述，检查工作应包含运行该依赖包自带的测试代码。但是，即使包自带的自动化测试可以通过，你也应该在使用这个包之前，继续为你所使用的相应功能写自动化测试用例。
这些测试用例应是简短的、独立的程序，以便于日后容易理解你的 API 对应的测试。
如果你现在还没写测试用例，就立即写吧，回头是岸～
花些额外精力写测试代码是很值得的，因为即使将来依赖的包的版本升级了，你的功能也会有保障。若你发现一个 bug，并且你自己有可能修复它，那么你可以重新执行一次你项目的测试用例，以确定不会影响到其他功能。
运行基本的检测来发现可能存在的问题。
以代码搜索系统为例，根据经验，PCRE有时需要很长时间执行某些特殊的正则表达式搜索。最初的计划是将搜索分为「简单」和「复杂」两种正则表达式，并跑在互相独立的线程池中。
第一阶段的测试中，谷歌跑了一些对比和一些其他grep实现的基准测试。当在一个测试用例中发现比最快的grep实现慢了近 70 倍时，谷歌开始重新考虑是否还该继续用PCRE了。
尽管最后谷歌还是放弃了PCRE，但时至今天这个测试用例依然保存在我们的代码库中。
引用后的使用准则

下 做好依赖管理的十五条准则

下做好依赖管理的十五条准则