github 可持续
在隔离之前，我的一位前学生问了一个有趣的问题：如果此存储库上有问题，那么GitHub是否会向存储库所有者发送电子邮件？ 答案并不重要。 作为前顾问，我试图了解根本问题。 经过一番挖掘，我理解了：该学生正在使用他在GitHub上找到的项目。 该项目缺乏功能，问题在于要求它。 随便看了一眼，我意识到我个人从未使用过这样的项目。 原因是我已经对该项目进行了初步检查。 更重要的是，我还意识到这些检查并非对每个人都简单。 这篇文章旨在描述我在考虑依赖GitHub项目之前判断其可靠性的过程。
我将以学生的项目为例，但不涉及任何判断。
提交文件的时间戳
第一个指标是文件的提交时间戳。 如果最近一次提交已过期，那么这是一个不好的信号。 如果已经使用了几个月，则取决于其他提交。 关键是要进行或多或少的常规提交。
可从项目主页轻松访问此信息：
在此示例中，虽然有些文件是在几年前提交的，但有些文件是在最近提交的。 恕我直言，两个月完全可以接受。 这是一个好兆头。
多年未触及项目的唯一好理由是它功能齐全 。 可以很容易地进行评估：从文档中，或者很多第三方正在使用该项目。
自述文件
README文件是项目的标志，其贡献者认为正在被他人使用。 这样，它增加了对可靠性的信心。
如果没有README ，那么文档是一个很好的替代品-尽管我从未见过任何有文档但没有README文件的项目。
示例项目有一个很重要的README文件。 这是另一个好兆头。
许可文件
每个人都应该永远使用项目没有检查许可证。 缺乏许可证是一个强烈的信号，表明该项目的设计初衷不是供第三方使用。 更糟糕的是，使用这样的项目可能会给用户带来法律问题。
在GitHub上， LICENSE文件是传达许可证的标准方法。 它应该是官方的开源许可证之一。 谨慎使用非标准许可证。 尽管它们似乎更开放， 例如 “您想对公共许可证做什么” ，但它们也有法律风险。 除非是非公开工作，否则请仔细评估。
该示例项目使用标准的MIT许可证。 到目前为止，一切都很好。
贡献人数
是否可以依赖项目的另一个指标是其贡献者的数量。 大量暗示着社区的兴趣和参与； 数量少，相反。
此外，它还与总线系数有关 ：
公共汽车因素是对因团队成员之间无法共享信息和能力而导致的风险的一种度量，该措词源自“如果他们被公共汽车撞到”。
但是，贡献者数量和总线因子之间的相关性不是很好。 贡献者的数量是在项目整个生命周期中实际贡献任何东西的总人数。 贡献可以是巨大的，也可以是很小的，并且是固定的或一生一次。 过去有人会很活跃，然后停止贡献。
因此，该单方面的指标应进一步细分。 这里很难谈论一般性，让我们看一下示例项目：
关于六个贡献者：
- 两个仅贡献一次， k和A
- 一贡献两， p
- 三个重要贡献者M ， J和c
在三个主要的贡献者中，我们可以看到，尽管c贡献不大，但他定期进行贡献。 同时， M是该项目的创建者，也是最大的贡献者。 但是，自几个月前以来，他就没有在回购协议上做任何事情。 再加上J的历史，似乎M将项目“交给”了J ：一个人可以看到重叠的一小段时间，这两个时间都对J产生了作用，而前者却没有，而后者开始了。
考虑到这一点，对该项目的信心有所下降。
贡献者历史
现在，一些贡献者可能最近并未对该项目进行勤奋的工作。 这是可以理解的，只要这只是暂时的打ic，而不是明确的趋势。
让我们看一下J的贡献历史：
从贡献图中，我们可以看到J从2019年5月开始贡献，到2020年3月停止。分布看起来很像高斯分布。 从该活动可以看出，最新的贡献是创建了J的GitHub Pages。
至此，我对项目可持续性的信任消失了。
摘要
尽管单个指标的意义并不大，但所有指标的矩阵都能很好地说明项目的可靠性。 但是，有些指标比其他指标要强。
| 指示符 | 强度 |
|---|---|
Commit timestamp |
|
|
|
|
|
Number of contributors |
|
Distribution of contributors |
|
Contributor history |
|
结论
限制一个人的依赖数量是一个崇高的目标。 但是，除非有人想重新发明轮子，否则在不平凡的软件开发工作中重用现有项目通常会更好。 除了广泛而著名的项目外，还必须谨慎行事，因为这取决于人们无法控制的代码库。 我希望这篇文章可以帮助程序员做出有关代码依赖关系的明智决定。
翻译自: https://blog.frankel.ch/assessing-projects-sustainability-github/
github 可持续