选择软件库或框架小小书 XXshu

我会尝试从使用的语言/运行时/平台（PHP，Java，.NET等）中抽象出来，因为这些概念是通用的。

可重用性是软件工程中的口号。避免“重新发明轮子”是使用库和框架的基本原理。不要开发非“业务核心”的软件。重做由专用于它的其他人创建，测试和维护的代码是没有意义的。这就是为什么要准备使用“打包”功能的原因。

平均复杂度较高的应用程序（例如Intranet，iOS应用程序）可以使用数十个库和某些框架。大多数都是免费的，许多都是开源的。

“问题”是有很多方法可以解决相同类型的问题。网络上有无数的优惠。从哪儿开始？如何过滤？有时，显而易见的选择可能很危险，因为这些选择可能掩盖了人们的偏见。谦虚地遵循消除这些偏见的过程。

首先，您应该询问您是否真的需要一个新的库或框架。您要解决的问题是其他人/项目的共同问题吗？如果是这样，肯定有人已经考虑过并解决了。在以下情况下，对库/框架的使用将成为补偿：

通用算法，例如排序或处理数据；
导入/导出格式（Excel，PDF等）；
创建缓存；
认证和授权；
动画（图形效果）；
XML或JSON的序列化和反序列化；
使用或提供REST API；
抽象网络通信；
多媒体播放器；
安全算法；
模板系统；
中介对象和表/关系（ORM）；
小部件工具包；
……等等。

如果您只打算利用库/框架的一小部分，则可能甚至不需要使用它。语言/运行时是否能满足您的大部分需求？您是否只需要一个微型库/实用程序，而无需一个庞大的框架？

当决定包括一个库时，应考虑以下因素：

额外的资源消耗（网络延迟，花费的编译，部署和运行时间，内存成本）
创建另一个技术依赖性，因此必须重新考虑您的软件体系结构以正确隔离它；
学习时间；
包含未知代码；
可能与其他软件不兼容。

使用框架时，除上述要点外，还应考虑：

如果选择不当，可能会浪费时间/精力；
程序员可能会忘记或忽略“幕后”发生的事情（例如，他们可能在不知不觉中生成缓慢的查询）；
可能的强制措施（即框架可以强加一种工作方式，并且很难不使用它）。

总之，如果您知道库/框架的弊端，可以在项目中添加库/框架。

既然您已经决定使用库或框架，您将做什么？现在是时候搜索并准备初步调查了。可能有数十个库/框架可帮助您实现目标。让我们消除假设。现在不是决定的时候，因此在此阶段不要进行深入分析-请记住，这只是初步调查。

必须非常清楚要解决的问题：存在抽象级别不同的问题（例如，订购列表的级别低于创建在线商店的级别），因此您应该使库级别与问题级别匹配。仅考虑链接到您的开发环境的解决方案（Node.js，Java，Swift）；忽略那些与要解决的问题几乎没有关系的东西；丢弃那些远不如您在中长期使用的产品。

堆栈溢出，维基百科和观点和/或比较文章是不错的起点。托管在GitHub上的项目具有为您提供元数据（例如，星号，请求请求，贡献者等）的巨大优势：

在此阶段，您大概有6〜10名候选人。

除了搜索引擎之外，图书馆存储库有时也是一个很好的起点（因为许多存储库具有良好的分类，大量的元数据，并且实现了一些“自然选择”）。例如：

对于Android，Android Arsenal；
对于PHP，Packagist；
对于Java / Kotlin，Maven存储库；
对于iOS，CocoaPods；
对于Node.js，使用npm注册表；
Ruby或RubyGems。

分析图书馆/框架的任务，其文档，样本/演示及其论坛/社区。如果可以，请避免使用“ 1.0”及以下版本；它们很可能尚未达到要求的期限。查看软件许可证，消除那些与您的问题无关的许可证。

图书馆和可信的企业框架或开源基金会（例如Google，Facebook，Pivotal，Apache Software Foundation，jQuery Foundation）提供的信任度要超过未知人员（但也有例外）。

经过分析，您应该将候选数减少到2〜5。如果仍然令人困惑或选择对项目起决定性作用（在框架中比在库中应用更多），请参阅决策矩阵（可选加权）。这样的矩阵可以帮助巩固/记录这些研究并将其呈现给决策者。

衡量人气的一种方法是使用Google趋势。例如，您可以检查AngularJS vs Vue.js vs React JS的趋势。

在下面的Wikipedia示例中，我们看到了Java Web框架的比较功能（与上表相比，各行用列切换）：

不要问“最好的图书馆是什么？”这个问题。而不是“解决此问题的最佳库是什么？”

避免根据心血来潮或好奇心来决定事情。摆脱空洞，情感或主观的论点：

«我已经使用过并且喜欢它»
«Facebook的使用非常壮观……»
“着火了！每个人都在使用它！ »

仅关注技术和事实争论：

库与要解决的问题之间的对应程度是多少？
文件的质量/数量是多少？
版本多久（最后一次是哪个）？

现在该进行实验了（PoC，原型或试点）。着重于实现一个或两个关键的“自顶向下”功能，这些功能使库/框架能够显示其优缺点。为此，请考虑问题/项目中的决定性操作。例如：“必须具有一个包含排序，过滤器和内联编辑的数据表”。哪些功能是不可以缺少的，没有它们，项目将失败？这些是您要在预选的库/框架中测试的库。

决策所涉及的努力必须与其重要性成正比。对于较小的图书馆，请花费更少的时间。对于决定性的框架，请花费更多。另一方面，您不需要应用所有提到的方法。有时，对GitHub的良好阅读足以使您对预过滤甚至决策充满信心。

PoC的目的是在无法实现您认为基本的目标的情况下考虑/丢弃它们。因此要平衡细节。每个PoC可以并行执行（由不同的开发人员执行）。您可以将它们存储在版本库中的分支中。

根据要求，还考虑比较性能测试。例如，如果您正在评估用于JSON解析的库，请进行详尽的测试，以使您能够在极端和异常条件下（例如，大文件，大节点等）评估每个库。为了补充分析并帮助您做出决定，请执行“ A vs. B”类型搜索（例如，“凌空vs robospice”，“ imageloader与glide”），并考虑已经使用过该工具的人员的意见。

最后，选择一个PoC作为赢家。所选的PoC代码库可用于该项目。