python开源模块_如何选择最适合您需求的开源模块

python开源模块

I really appreciate the current state of open source development. It may not be perfect, but I truly value the free flow of ideas and creativity, and the willingness of so many developers to share what they know and how they solve problems. Ultimately, this is what I think open source should be: solving problems and sharing answers.

我真的很感谢开源开发的当前状态。 它可能并不完美，但我真正珍视思想和创造力的自由流通，以及如此众多的开发人员分享他们所知道的知识和解决问题的方式的意愿。 最终，我认为开源应该是这样：解决问题和共享答案。

However, as with almost everything in life, this coin has another side: Not all answers are equal, and having too many choices can be almost as bad as not having any at all. Once I started writing software that relied on open source modules, I learned this reality pretty quickly. I eventually came up with a set of guidelines to help me make decisions and mitigate some of the inherent risk. Hopefully, you will find these guidelines useful in your searches, too.

但是，就像生活中的几乎所有事物一样，这枚硬币还有另一面：并非所有答案都是平等的，拥有太多选择几乎和根本没有选择一样糟糕。 一旦开始编写依赖于开源模块的软件，我很快就会了解到这一现实。 我最终提出了一套指导方针，以帮助我做出决定并减轻一些固有风险。 希望您会在搜索中找到这些指南。

These guidelines are not listed in any particular order. I try to consider all of them equally and make my final decision based on an overall score.

这些指南未按任何特定顺序列出。 我会尝试平等地考虑所有因素，并根据总体得分做出最终决定。

(Note that while my background and viewpoint is primarily based on the JavaScript ecosystem, these guidelines are applicable across all languages that share and use open source modules. The principles are pretty much language-agnostic.)

(请注意，尽管我的背景和观点主要基于JavaScript生态系统，但这些准则适用于共享和使用开放源代码模块的所有语言。这些原理在很大程度上与语言无关。)

考虑作者 (Consider the Author(s))

We can’t know all open source authors personally, but there are some indicators that should help us:

我们无法亲自认识所有开源作者，但是有一些指标可以帮助我们：

• Are they well known within their community?
  他们在社区中众所周知吗？
• How many modules have they published?
  他们发布了多少个模块？
• How many stars/forks/contributors/followers do their GitHub repos have?
  他们的GitHub回购有多少个明星/分叉/贡献者/追随者？
• What is their overall level of contribution activity?
  他们的总体贡献活动水平是多少？
• Do they respond well to issues and PRs?
  他们对问题和PR是否React良好？
• Are the modules updated in step with the language or engine they are based on?
  是否已根据模块所基于的语言或引擎来更新模块？

The idea here is to formulate some sense of their overall commitment and interest in open source development, as well as their relationship with other community members, and their awareness of how the ecosystem is evolving around them.

这里的想法是表达他们对开源开发的总体承诺和兴趣，以及他们与其他社区成员的关系，以及对生态系统如何围绕他们发展的意识。

Does this mean that we should only be interested in utilizing code written by the top 1%? Not necessarily. Being popular is not synonymous with being best. However, my experience has shown that reliability and consistency is a very important concern when using pretty much anything developed by someone else.

这是否意味着我们只应该对使用收入最高的1％的代码感兴趣？ 不必要。 受欢迎并不是最好的代名词。 但是，我的经验表明，在使用几乎任何其他人开发的东西时，可靠性和一致性是一个非常重要的问题。

考虑文档 (Consider the Documentation)

Documentation is key. Good documentation will significantly sway my opinion about an open source module:

文档是关键。 好的文档将极大地影响我对开源模块的看法：

• Does the module have a README?

  该模块有自述文件吗？

• Does the documentation include code samples of real-world usage, and do the samples actually work?
  该文档是否包含实际用法的代码示例，并且这些示例确实有效吗？

• Is there a CHANGELOG? Or are changes adequately described in release notes?

  有CHANGELOG吗？ 还是在发行说明中充分描述了更改？

• Can I understand the documentation well enough to make the best use of the module? (Admittedly, this may only become apparent after you start using the module. C’est la vie.)
  我能否充分理解文档以充分利用该模块？ (不可否认的是，这只有在您开始使用该模块后才会显现出来。请访问。)
• If there is a lot of information to convey, is the documentation broken out into separate files or pages? Are those sources understandable?
  如果要传达大量信息，文档是否分解为单独的文件或页面？ 这些资源可以理解吗？

Some developers may argue that code should be self-documenting or that unit tests should adequately fill the need of showing how code works. While I definitely agree with this viewpoint in theory, in practice I don’t want to spend hours or even days reading code just to figure out how it works. Please provide us with a good reference document and make sure it’s kept up to date. This is part of our job as professional software developers, and all of us should be setting a good example for one another.

一些开发人员可能会争辩说代码应该是自我记录的，或者单元测试应该充分满足显示代码工作原理的需要。 虽然我在理论上绝对同意这种观点，但实际上，我不想花数小时甚至数天时间来阅读代码，只是想弄清楚它是如何工作的。 请为我们提供良好的参考文件，并确保其为最新。 这是我们作为专业软件开发人员的工作的一部分，我们所有人都应树立榜样。

考虑守则 (Consider the Code)

I don’t necessarily take the time to read every line of code in a module that I am considering using in my project. But I do check for the basics:

我不必花时间阅读我正在考虑在项目中使用的模块中的每一行代码。 但我会检查基本知识：

• Does the module follow a coding standard? A good way to check is if the module includes a lint command, or if the README indicates that a standard is being followed.

  模块是否遵循编码标准？ 检查模块的好方法是模块是否包含lint命令，或者自述文件是否指示正在遵循标准。

I do have my own preference for coding in JS, but I’m not super concerned about which standard is used, as long as a standard is used. This is important because there’s a good chance that I will need to consult a module’s source code at some point in time, and I do not want to deal with code that is poorly formatted.

对于JS编码，我确实有自己的偏好 ，但是我并不担心使用哪种标准，只要使用一种标准即可。 这很重要，因为很有可能在某个时间点需要查阅模块的源代码，并且我不想处理格式错误的代码。

• Does the module include automated tests? Are those tests automatically run by a CI system, and does the README include a badge indicating the current build/test state?
  该模块是否包括自动化测试？ 这些测试是否由CI系统自动运行，并且自述文件是否包括指示当前构建/测试状态的标志？

Cloud-based continuous integration services are so ubiquitous these days that I don’t think there is a reasonable excuse not to use them, even for the smallest of projects.

如今，基于云的持续集成服务无处不在，我不认为有合理的理由不使用它们，即使是最小的项目也是如此 。

(There is a side note that I think is important to mention here. Just because a badge indicates that the latest build failed, it doesn’t mean the build actually failed. Sometimes web caching gets in the way of indicating the true status, and so I always click on these badges to check for myself. I’ve also found that the build matrix may include environments or versions that I’m not concerned about, and their failure may or may not be an issue.)

(有一个旁注，我认为在此值得一提。仅仅因为一个徽章表明最新的构建失败，并不意味着该构建实际上就失败了。有时Web缓存会阻碍显示真实状态，并且因此，我总是单击这些标记进行自我检查。我还发现，构建矩阵可能包含我不关心的环境或版本，它们的失败可能是(也可能不是)一个问题。)

• Does the module use Semantic Versioning, and is the current release at 1.0.0 or higher?

  该模块是否使用语义版本控制 ，并且当前版本是1.0.0还是更高版本？

SemVer isn’t always the easiest concept to apply correctly, but I always award points to those who are trying. I also tend to avoid modules that are stuck in “not ready for prime time” mode (meaning, they proudly indicate they are major version 0 and were initially released months or years ago), even if they are at least somewhat popular and fill an important need. To me, this is a big red flag. Remember what I said above about reliability and consistency? I’ve come to the conclusion that using SemVer is a sign of respect and consideration for others. We should stand by our work, and if we’re ready to release something “into the wild,” so to speak, then we should at least provide and communicate some guarantee about stability.

SemVer并非总是最容易正确应用的概念，但是我总是向尝试的人奖励积分。 我还倾向于避免陷入“尚未准备好迎接黄金时段”模式的模块(这意味着，它们自豪地表示它们是主要版本0，最初在几个月或几年前发布)，即使它们至少在某种程度上很流行并且填充了重要需求。 对我来说，这是一个很大的危险信号。 还记得我上面所说的可靠性和一致性吗？ 我得出的结论是，使用SemVer是对他人的尊重和考虑的标志。 可以说，我们应该坚持自己的工作，如果我们准备将某些东西“放之四海而皆准”，那么我们至少应该提供并传达一些关于稳定性的保证。

• Does the API generally conform to a style or pattern (functional vs. imperative, fluent, declarative, etc.) that I’m comfortable programming against?
  API是否通常符合我喜欢编程的样式或模式(功能性与命令性，流畅性，声明性等)？

API design is a little tricky to get right, and some APIs definitely make more sense than others. One of the good things about having multiple choices between different modules is that we can often pick one that matches our preferences.

API设计有点棘手，有些API肯定比其他API更有意义。 在不同的模块之间进行多种选择的好处之一是，我们经常可以选择一个与我们的偏好匹配的模块。

底线 (The Bottom Line)

To me, reliability and consistency are really important when choosing open source modules. In fact, there are a number of tools out there that attempt to answer these questions automatically (for JavaScript in particular, there are sites like npms.io), which means that other developers are concerned about these issues, too.

对我而言，选择开源模块时，可靠性和一致性非常重要。 实际上，有许多工具可以尝试自动回答这些问题(特别是对于JavaScript，有npms.io之类的网站 )，这意味着其他开发人员也担心这些问题。

I like the idea that some of this work can be automated, but at the end of the day, I’m the one who’s ultimately responsible for making the decision. So I want to be involved in the process. I also don’t like the idea of solely relying on “curated” or “best of” lists, because I’ve often found they either aren’t up to date or aren’t original.

我喜欢某些工作可以自动化的想法，但归根结底，我是最终负责做出决定的人。 所以我想参与这个过程。 我也不喜欢仅依靠“精选”或“最佳”列表的想法，因为我经常发现它们要么不是最新的，要么不是原始的。

Two final thoughts:

最后两个想法：

1. Yes, this process is a little time-consuming, but I don’t think there’s any way around that. From my perspective, it’s worth spending a few hours (or even days) doing some detective work if the lifespan of my application that depends on these modules is measured in months or years.
   是的，此过程比较耗时，但我认为没有任何解决方法。 从我的角度来看，如果我的应用程序依赖于这些模块的寿命以几个月或几年来衡量，那么花几个小时(甚至几天)做一些侦探工作是值得的。
2. This process does not provide an absolute guarantee of success. There is still some risk involved, but there are additional defensive measures that can be taken, which I will discuss in a future article.
   此过程不能绝对保证成功。 仍然存在一些风险，但是可以采取其他防御措施，我将在以后的文章中进行讨论。

翻译自: https://medium.com/better-programming/how-to-choose-the-best-open-source-module-for-your-needs-a205c1defd62

python开源模块