在使用 Laravel 扩展包之前必须问的 8 个关键问题

简介

Laravel 和 PHP 的一个令人惊叹之处是提供丰富的社区包生态系统，这些包可以加速您的开发过程。通常，一个好的包可以帮助您比从头开始编写代码更快速地实现网站应用中的复杂功能。我喜欢找到完全符合我需求的包的感觉——这保持了我的工作乐趣，并让我感激开源社区的付出。我自己也维护一些开源包，例如 Laravel Exchange Rates、Short URL、Laravel Config Validator 和 Favicon Fetcher。

然而，我们应谨慎对待迅速寻找包的潜在权衡，因为您项目中添加的每个包都是一个无法控制的对外部依赖。

在这篇文章中，我将介绍八个让我决定是否使用包时经过的想法。

1. 你能自己编写代码吗？

在使用包之前，考虑您是否能自己编写代码。如果您需要编写和维护的代码过于复杂或耗时，那么寻找包是一个很好的选择。然而，您需要评估使用由团队外部人员维护的包所带来的代码复杂性和维护额外的成本。

例如，假设您需要向Digital Ocean API 发送请求。使用Digital Ocean的PHP包会更有意义，它经过测试，支持诸如身份验证和正确的HTTP请求等复杂功能。自己尝试编写这段代码是没有意义的。

然而，对于检查数字是否为奇数这样的简单功能，最好是自己编写，以避免外部依赖。难以置信，这个JavaScript库每月下载量达到25k+！

2. 包会不会限制您？

与包一起工作的好处之一是，您可能会感觉到您正像拼图一样构建应用程序——将多个小型包拼接成一个大型应用程序。然而，由于包通常设计为通用和与代码库其他部分解耦，它们并不总是符合您的预期工作流程。

例如，看看我的Short URL包：这是一个Laravel包，允许您在Laravel应用程序中创建缩短的URL。我在构建此包时的主要目标是使其尽可能简单，以便您可以在项目中安装和使用。理想情况下，安装、配置和使用仅需几分钟时间。

我确信该包非常适合创建缩短的URL并将它们存储在数据库中。然而，对于像批量创建缩短的URL这样的操作就不太适合，因为它是在数据库中逐个插入缩短的URL（也就是说，一次创建1,000个缩短的URL，需要1,000次数据库插入）。显然，这效率并不高，但我对此局限感到满意。

在我看来，如果您正在构建一个真正需要一次性批量插入1,000个缩短的URL的应用程序，您应该使用为该特定用例构建的包。如果您找不到合适的包，请自己实现该功能，并考虑发布新的包。

关键是要始终问自己，包是否完美地符合您预期的工作流程，或者您是否需要做一些修改才能使其工作。如果您不确定，请尝试在测试git分支上安装该包，并对其进行实验以看是否符合您的需求。如果包与您的要求不符，您始终可以选择回滚并探索其他想法。

同时，如果您发现包中存在潜在的问题和/或错误，并有一些解决方案，请考虑提交一个拉取请求来改进该包。《向开源项目贡献可以非常有益，有助于其他遇到相同问题的开发者。

3. 包是否仍在维护？

当您查看一个包时，检查它是否仍在维护非常重要。

如果包已经过时或不再维护，那么在项目中使用它是有风险的。例如，假设您在PHP 8.2上使用了一个包来实现一个重要功能，但现在您想要将项目更新到PHP 8.3。如果该包不支持PHP 8.3，且不再被所有者维护，您将不得不做出以下一个困难的决策：

要求（或希望）包维护者添加对PHP 8.3的支持。
提交一个拉取请求来添加对PHP 8.3的支持，并希望他们合并它。
使用不同的包在您的应用程序中重新实现功能。
自己重写代码。
分叉包并开始维护自己的版本。
继续使用PHP 8.2。

坦白讲，这些听起来都不是特别理想。我们希望继续在应用程序中构建新的酷功能，而不是担心维护现有的功能。

那么，你是如何知道一个软件包是否仍在维护呢？以下是一些检查方法：

检查仓库中是否有陈旧的未解答或未关闭的问题。
检查是否有老旧但活跃的拉取请求。
检查上次提交到代码库的时间。

注意：没有最近提交并不总是坏事。它可能意味着软件包已经迈入成熟或功能完善，只需未来进行安全更新（例如 PHP/Laravel 更新）。在使用或决定是否使用软件包时，每个软件包都要单独评估。

4. 软件包有测试吗？

决定是否使用软件包时，考虑其是否有测试也是一个重要因素。

当你安装一个软件包时，它就成为了你的项目代码的一部分。由于你编写代码时不会不编写测试（对吗！😉），确保软件包有一个高质量的测试套件是非常重要的。一个好的测试套件可以最小化软件包引入可能导致应用程序崩溃的新错误的风险。

注意：没有测试并不一定意味着有错误。事实上，如果软件包相对较新，维护者可能仍在编写测试。个人来说，在我构建了我的第一个软件包之后，我学到了编写测试的重要性（阅读我的经验）。

5. 软件包有良好的文档吗？

良好的文档是被严重低估但非常重要的软件包的一部分。

没有什么比遇到问题而无法在网上找到任何文档更糟的了。我曾被迫与一些 API 和具有过时（或不存在）文档的软件包一起工作，而这并不有趣。这会减慢你的进度，迫使你花费更多时间深入了解软件包的代码，而不是开发新功能。

良好的文档有助于你了解软件包的工作方式。

6. 代码质量好吗？

有时候，深入了解软件包的代码并检查其整体质量是有价值的。

正如我之前提到的，当你安装软件包时，它就成为了你的项目代码库的一部分。如果你接受一个团队成员的代码质量差、有错误或潜在的安全漏洞的拉取请求，你会怎么做呢？在考虑第三方软件包时，你需要同样思考。

代码不需要完美，但你希望避免在包含它时引入任何明显的错误或安全漏洞。

7. 软件包受欢迎或值得信赖吗？

一般来说，值得信赖的开发者的流行软件包更有可能得到未来的支持和维护，使其使用风险更低。

这些指标加在一起，应该给你一个关于软件包受欢迎程度的印象

总下载量（或每月下载量）
贡献者数量
使用它的项目数量
维护软件包的开发者
GitHub 上分支的数量
GitHub 上的星标数量
GitHub 上的关注者数量

例如，让我们看看在撰写本文时 Spatie 的 Laravel Permission 软件包的这些指标

总下载量为 2500 万
176 位贡献者
54700 个项目在使用它（根据 GitHub 的数据）
1730 个分支
10900 个 GitHub 星标
199 个 GitHub 关注者

我不知道你，但在我看来，这似乎是一个很受欢迎的包装程序。这些数字让我有信心，与只有一个贡献者且没有星标的包装程序相比，这个包装程序不会很快消失。

注意：请记住，每个人都必须从某个地方开始。也许你已经找到一个适合你项目的完美匹配的包，但它是由一个刚开始的人维护的。当我第一次构建Laravel Exchange Rates时，需要一段时间才取得显著的下载量——我完全理解。当$Laravel新闻李华 news分享此包时，兴趣终于激增。因此，如果你发现一个高质量但不太流行的包，并不一定意味着它不好；你可能只是起步较早。