
本文字数:2372;估计阅读时间:6 分钟
作者:Alexey Milovidov
本文在公众号【ClickHouseInc】首发

起初,我只是想做一份报告,用来激励管理者关注并解决 GitHub 上的问题。但后来越做越复杂,干脆做成了一个网站,在上面可以对比多个 GitHub 仓库中团队活动的各种指标。你可以点这里看看(https://velocity.clickhouse.com/#org=ClickHouse&metric=all_activity&range=all&grouping=auto&alexey=0&everyone=0)。

这样做其实并不合理
关于“开发者生产力”这个话题,一直都颇具争议。我真心希望现在已经没人还在用“代码提交行数”来衡量开发者的工作了(https://www.folklore.org/Negative_2000_Lines_Of_Code.html)。但如果你只是换了一种方式,比如统计提交次数(commit)和 Pull Request 数量,其实犯的是同样的错误。这些都不是公司真正的核心工作内容,而它们的数量也无法准确反映一个人所做的贡献。
当然,出于好奇看看这些数据没什么问题,从宏观层面也许能发现一些趋势,但它们不应成为优化目标。最多只能作为一些次要的参考信号。

不过它仍然有意义
任何团队内部的指标,本质上都是不准确的!所以我干脆加了一个功能,让你可以比较 GitHub 上任何仓库、任何组织之间的指标。
比如:
Rust vs. Zig | Polars vs. Datafusion | Superset vs. Metabase | Node vs. Deno | Node vs. Bun | SurrealDB vs. ArangoDB | Elasticsearch vs. Opensearch | Redis vs. Valkey | Tensorflow vs. PyTorch | QDrant vs. Weaviate | Supabase vs. Neon
你可以看到某个人是从什么时候开始参与项目的,也可以看到他/她什么时候不再活跃;还能查看社区规模的分布情况,以及一个项目的整体活跃度变化趋势。某个项目是否受欢迎,也可以通过它收到的 GitHub issue 数量来粗略判断(包括功能请求、bug 报告、问题咨询等)。
当然需要提醒的是,不同项目之间并不总是具有可比性,甚至可能会产生误导性结论。比如 Spark 和 MongoDB 并不使用 GitHub 的 issue 系统,而是要求用户去注册 Jira;Linux 内核既没有 issue 也不使用 Pull Request;LLVM 刚刚从 Phabricator 和 Bugzilla 迁移到 GitHub,现在更容易访问了;而 GCC 在 GitHub 上只是一个镜像仓库;Chromium 也同样没有使用 GitHub 的 issue 或 PR 系统。对于很多成熟的开源项目来说,依赖 GitHub 进行问题管理,反而是少数派。
实现方式
这个网站采用单页 HTML 应用的形式,前端直接连接到 ClickHouse 数据库。所有查询均由一个只读用户执行,并设置了访问限制和资源配额。关于数据库设计与数据采集的细节,可参考我在 2020 年发布的这篇文章(https://ghe.clickhouse.tech/?_gl=1*l7juqy*_gcl_au*MTcxNTI5MTA5MS4xNzY0MDc0ODU2)。
整个项目在用户体验上也融入了一些巧妙设计。
在仓库选择器中,你既可以输入组织名(如 ClickHouse)、指定单个仓库(如 ClickHouse/ClickHouse),也可以使用通配符(如 apache/superset*),甚至一次输入多个目标。系统支持在所有 GitHub 仓库中进行模糊搜索,并根据 Star 数量对匹配项排序,提供高效的筛选建议。
图表采用了 “horizon chart(地平线图)” 的可视化方式,可在有限空间内呈现高密度信息。我们还通过颜色区分不同仓库的活跃情况,清晰展现我在 ClickHouse 和 ClickBench 等项目中的贡献时段。
在作者列表中,点击任意开发者即可在 ClickHouse SQL UI 中查看其完整的活动记录;点击图表上的某个数据点,则可以深入查看该时间段的具体事件。为了保持报告的准确性,还可以移除某些作者,用于过滤掉自动化脚本或异常活动的干扰。
该网站的源代码已开源,点击这里即可访问(https://github.com/ClickHouse/velocity)。

成果感受
整个网站仅用了半个周末就开发完成,这让我至今仍感到惊讶。用 ClickHouse 构建分析类应用、数据探索工具和可视化仪表盘的过程简洁高效,充满乐趣!在易用性方面,ClickHouse 的表现可以说是遥遥领先,几乎没有其他数据库能与之比肩。
征稿启示
面向社区长期正文,文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号,优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至:Tracy.Wang@clickhouse.com


被折叠的 条评论
为什么被折叠?



