关于 ietf rfc 和 k8s kep

无论是 IETF RFCs, 还是 K8S KEPs,亦或是Pyton PEPs 、 Rust RFCs,都是为了解决一个问题:如何解决项目发展到很大规模时的功能协作问题。

名词释义:

  • IETF RFC - IETF Request For Comments: IETF 意见征集稿
  • K8S KEP - Kubernetes Enhancement Proposal: k8s增强特性提案
  • Pyton PEP - Python Enhancement Proposal:Python改进建议书
  • Rust RFC - Rust request for comments

这些形形色色的 RFC/Xep 在不同语境下意思也不完全一致,具体看社区达成的共识。无论是什么场景,初心都是有利于不同角色间的协作。以下是我整理的一些好处:

  • 对于项目管理人,能够跟踪重大功能从概念到实施整个路径。
  • 对于PM(项目经理、产品经理),以一个连贯的叙述,向外界阐述为什么这个特定的版本很重要。
  • 对于项目核心开发人员,需要一个前瞻性的路线图(roadmap)来规划什么时候落地那些特性。
  • 对于开发经理等,通过 rfc 快速掌握全局,安排开发工作。
  • 对于开发者,通过编写 rfc 理清自己的思路,避免过早的陷入实现细节。
  • 对于社区,可以加强沟通,扩大知识的范围,避免知识掌握在少数人手中。
  • 对于新人,通过 rfc 了解项目发展历程,更好融入社区
  • 对于一定经验的从业人员,通过 rfc 跟进社区动态,获知业内的最佳实践方案,调整学习方向,改进工作业务的内容
  • 对于资深的黑客,通过 rfc 了解本技术的特性,与其它同类社区的差异,为什么要设计这些特性,是怎么设计的,怎样更好地运用(攻破)它们

当然,一个东西当然不可能仅带来优点而没有缺点:

  • 写文档,不是所有人都愿意去做。
  • 额外的流程,会降低我们的开发速度。
  • 项目管理人员也需要花费额外的心思维护和处理rfc相关的工作。

至于有的人说什么开发圣经之类的,个人觉得也大可不必,rfc 就是一个记录设计思路的文档,掌握思路和背后的思考,才是我们开发者应该关注的。

rfc 经过长年累月会累积产生特别多的内容,我们并不需要对每个rfc都熟知,也没有必要,一般快速了解全貌,再针对性看个人感兴趣的。

ps: 写文档和写单元测试一样,虽然开发者可能不太喜欢,但还是要坚持才行啊。

参考资料


如果本文对你有帮助,欢迎投食

《哥白尼世界的起源》英译者导言 - 张卜天 译 kubernetes 版本更新记录(1.11-1.22)