关于 ietf rfc 和 k8s kep
2021-08-03 tech dev 3 mins 1165 字
无论是 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: 写文档和写单元测试一样，虽然开发者可能不太喜欢，但还是要坚持才行啊。