Kubernetes是个体量可观的大项目。这里说的“大”，指的不单单是愿景野心，同时也体现在源代码量层面。截至本文撰写之时，该项目拥有超过86000条提交、2000多位贡献者、2000多个开放问题、1000多个公开PR以及超过61000星。绝非虚言，大家打开项目的GitHub页面即可求证。

根据计算，目前Kubernetes项目的go源代码量超过430万行（总代码量已经超过520万行），“actual”行超过300万，注释行也已经达到70万以上。项目的总文件数为16000多个，其中包括vendor/目录。

我们的工作是通过一套代码库显示项目中的TODO注释量，希望帮助开发人员借此执行各类基础性项目管理流程。

这一次，我们决定利用一款小型TODO查找器对Kubernetes源代码进行一番筛查，看看结果究竟如何。下面来看我们的发现。

我们针对commit 9bf52c2的源代码运行了tickgit。该CSV输出结果随后会被导入至SQLite以运行其他后续查询。请注意，该工具仅从已检出的提交当中查找TODO注释；曾经添加，但随后被删除的TODO部分不会被计入在内。因此，我们得出的数字将仅反映查询时仍“活动”于代码库之内的TODO注释。

总体情况(9bf52c2)共存在来自363位不同作者、1230个文件的2380条TODO
其中460条TODO注释指向明确待办人，例如 // TODO (patrickdevivo) Fix the …
截至目前，2019年年内新增TODO数量为489条
单一TODO的平均存在周期为860天（折合2.3年）
最早的现存TODO创建于2014年6月6日来自首次提交
最新的TODO来自2019年12月9日
单一文件中的最高TODO数量为33条
deads2k提交的现存TODO（git blame）量最高，为147条
此次提交一次性添加了最多TODO（仍在源中），为64条

结果汇总计数	文件路径
33	cluster/gce/util.sh
25	pkg/apis/core/types.go
23	staging/src/k8s.io/api/core/v1/types.go
21	staging/src/k8s.io/legacy-cloud-providers/aws/aws.go
20	staging/src/k8s.io/code-generator/cmd/conversion-gen/generators/conversion.go
20	pkg/apis/core/validation/validation.go
16	test/e2e/network/service.go
16	pkg/kubelet/kubelet.go
14	test/e2e/framework/util.go
14	pkg/kubelet/kubelet_pods.go

包含TODO最多的文件

作者	计数
deads2k	147
Clayton Coleman	105
Chao Xu	99
Dr. Stefan Schimanski	93
Jordan Liggitt	81
David Eads	60
Random-Liu	54
Wojciech Tyczynski	50
Yu-Ju Hong	43
Prashanth Balasubramanian	38

提交TODO最多的作者

计数	sha
64	6a4d5cd7cc58e28c20ca133dab7b0e9e56192fe3
19	e01ff1641c7321ac81fe5775f6ccb21aa6775c04
19	4fb28dafad121e163fa86dc90067ce3d14415811
18	adb75e1fd17b11e6a0256a4984ef9b18957d94ce
14	963c85e1c807efcdbb82dd44439dc3c55f6a0bfd
14	8b17db7e0c4431cd5fd9a5d9a3ab11b04e2f0a7e
13	f0f78299348afcf770d4e8d89dcea82f80811b28
11	d0b94538b9744d0c06df6ddec2604be168568f9d
10	f1248b9c829e225138ab6d6234221c63092f7592
10	cd663d7ad00937cffa8a09e4761acb95d34c89a3

添加TODO最多的提交

计数	年份
34	2014
249	2015
523	2016
650	2017
435	2018
489	2019

各年份新增TODO数量

大家可以使用tickgit todos --csv-output获取原始TODO数据，得出与我们相似的查询结果。以上汇总内容来自SQLite。

结论与问题这些结果未经任何处理与预设，完全是对Kubernetes源代码当中TODO注释的即时整理。我们对TODO的主要来源也比较明确，其中大部分由Kubernetes项目的顶尖贡献者创建。

我们还发现，虽然Kubernetes这种大规模项目的体量可观，但开发人员在TODO注释方面的行为模式与小项目没什么区别，只是绝对数量更高。

一大重要发现是，与GitHub提问相比，TODO注释的数量更多。这是种有趣的现象，因为TODO代表着大量潜在的“工作内容”或者待办事项，而且除非我们亲身参与源代码开发，否则TODO对普通用户的提示性并不强。

核心贡献者们可能非常熟悉自己负责的代码库部分，也对自己的TODO与“潜在工作”了然于胸。但是，这一切在外部观察者看来毫无透明性可言。相比之下，GitHub提问或者其他公开的交互跟踪机制显然更为便捷易用。

很多开发者朋友应该都清楚，软件项目本身类似于“生命体”。它会不时变化、持续改进、不断完善，同时带来大量讨论。工作流与流程安排非常重要，因为只有不断反思才能成就高质量的代码。通过在Kubernetes源代码当中的TODO注释，我们得以一窥反思的力量。然而，由于缺少相关基准，TODO注释的平均存在周期长达2.3年，相当夸张。不过这里我们不敢评价太多，毕竟只有真正熟知项目内情的核心贡献者，才能断言2.3年算不算太长。接下来如果有机会，我们打算将Kubernetes的TODO周期与其他大型开源项目进行一番比较，相信结果会更有启发意义。

如果要对代码库中的TODO注释进行更深入的分析，我们可能需要纵观项目发展历程中曾经出现的所有TODO，而不仅仅是仍存在于当前源代码中的TODO。

TODO的平均关闭周期是多长？
TODO注释的平均生命周期是多长？
不同流行代码库之间的TODO注释有何区别？

这事……有意义吗？当然有意义。TODO注释所涉及的工作类型往往是那种不值得单独发一条申请，但却又比较重要的内容，因此有必要在代码行内做出注释与描述（当然，很多TODO也会引用问题/申请）。由于属于代码的组成部分，因为TODO与待完成工作往往“更加接近”。TODO易于添加，但也很容易被遗忘（目前，Kubernetes源代码当中仍然包含1800多条2019年之前添加的TODO）。

我们希望能够创建一款显示相关代码元数据的工具，确保软件开发人员能够更轻松地完成规模不同、类型各异的项目，而显示TODO信息只是其中的一部分——当然，也是非常重要的一部分。

原文链接：

https://medium.com/@augmentable/looking-at-kubernetes-2k-todo-comments-b2db42dc7fdb

创作场景

再无下文：Kubernetes 上众多 TODO 注释遭到遗忘