主页 / 问题 / 586685
Accepted
Alexey Prokhorov
Asked:2020-11-04 15:53:11 +0000 UTC2020-11-04 15:53:11 +0000 UTC

15MB 的依赖项或您的自行车哪个更好？

  • 772

在开发公共 npm 包时，经常会出现这样的问题：是使用现有的解决方案来提取几乎所有流行的 npm 包的一半，还是编写自己的自行车。

为了缩小范围，我会澄清细节。你的自行车大约有 1000-1500 行代码，没有依赖项，当然有可能会产生很多错误（但这是多么幸运）。开发和调试时间 - 一两天。另一种选择是完美解决此问题的包，但拖拽了约 150 个嵌套依赖项约 15mb。

你认为什么是可取的？在这种情况下，您首先根据什么标准来决定做出什么选择？

javascript

2 个回答

  1. 在 npm 世界中，通常会拉取更多依赖项。这是输出：

    • 如果这是您的个人项目，那么您可以随心所欲。在个人项目中，自行车是正确的（如果项目的目标是掌握新技术）。
    • 如果这是一个“尝试”、“起飞/不起飞”（又名启动）的项目 - 那么更多的依赖性，更少的代码。对我们来说，想法是检查，取悦潜在投资者，而不是舔代码。然后，也许，重写是可能的。
    • 如果这是一个工作项目（也就是说，它是在工作中完成的），那么最好问问经理/组长/之类的。如果是团队领导/经理本人，那么分数更高。但在这里，法律部门可能会说某些包裹的“许可证不正确”或“来源可疑”，您必须自己制作。

    但还有一件事。你需要看看，什么样的依赖关系。那里几乎没有。也许他们收集机密信息并将其发送到垃圾箱。而且已经有先例了。

    我也喜欢下面的系统。我们从现成的包中组装项目，看到它们具有“良好”的许可证，并有可能进行修改。然后，当项目“似乎正在运行”时，我们开始清理、重写关键部分。例如，您可以使用一个大包中的一个小函数。将它提取到您自己的单独包中很可能是有意义的。尽管现在时髦的优化者会跑过来说：“如果明天需要另一个功能怎么办？又要提取什么？磁盘现在很大，有很多内存，用户会购买额外的处理器。” 但这些需要被忽略并使用常识。

    • 22
  2. Best Answer

    在软件开发中，有 KISS 原则（保持简单，笨蛋——“让它更简单，笨蛋”）。非常合乎逻辑，在 * nix 系统中它很常见。我认为，在一般情况下，您需要按照它进行操作...

    但。你需要清醒地评估你的决定的目的和目的，以及第三方的决定。如果它是由著名的可靠开发人员创建、维护和开发的，如果您需要的功能不在该解决方案的“端”。那为什么不呢？也值得深思。拉集：它在使用您的解决方案的项目中非常有用的可能性有多大；是否很可能与类似的解决方案（或版本差异）发生冲突。了解此功能在您的项目中的重要性也很重要。也许你会把这 1500 行写一次并持续很多年，这是一回事。（那么这个选项就很合适了） 其他，如果保证这1500行既需要支持又需要开发，结果会减少开发主要功能的可用时间

    作为用户，这个故事是不合时宜的：他们要求我以某种方式将 LAMP 放在干净的 Windows 上。如果我没记错的话，MySQL 安装程序是用 .Net 编写的。结果，为了安装不需要 .你的自行车更好......

    • 12

相关问题