Gravitino Committer 成长之路（2）

如何成为 Apache Committer

根据 How to become Hadoop Committer的说法，成为核心开发者是一个漫长的过程：

1. 具备编写高质量代码的能力，能够遵循规范的开发流程，并根据他人的反馈不断迭代优化方案，提供切实可行的技术解决方案；
2. 善于撰写高质量的测试用例与技术文档，提升项目的可维护性与稳定性；
3. 从简单的任务做起，逐步参与到核心功能的开发中，善于在协作中不断提升自我；
4. 能够有效融入团队，展现出良好的协作能力和工程素养，这正是开源协同开发的本质。

同时，他们还给出了几个不建议的行为

1. 不要以为提交了几个 Patch 就能获得 committer 身份，这是一个需要长期积累的过程；
2. 不要因为英语不是母语而自我设限，语言不是参与社区的门槛；
3. 在赢得团队信任、证明自己具备足够的技术能力之前，避免贸然对核心模块进行大规模重构。

关键路径

根据前文的介绍，我个人理解成为 Apache Committer 的关键路径如下：

1. PR 数和代码量
2. 核心 Feature 数
3. 技术认可度

PR 数和代码量

持续、稳定地输出高质量 PR 是成为 Committer 的前提。数量体现参与度，质量体现价值。包括但不限于：Bugfix、Refactor、Feature 实现、Test 补充、Doc 维护等。

核心 Feature 数

核心 Feature 是衡量 Committer 价值的关键指标，也是核心要求。核心 Feature 通常涉及架构改动、接口设计或多模块协同，要求开发者具备全局视野与系统思维。体现了开发者技术深度与推动能力。

技术认可度

技术认可是获得 Committer 身份的关键标准。包括 code review 质量、沟通方式、对社区规范的理解与维护等。同时应具备 ownership 意识，能维护模块、支持新手、参与 Issue 跟进等。

总结

归根结底，核心在于信任。无论是提交 PR、实现核心功能，还是展现技术深度，背后真正积累的，都是社区对你的信任分。当 PMC 认为某位开发者值得托付时，Committer 的角色自然水到渠成。因此，前文提到的三个关键路径，其实都可以归结为一个核心问题：如何稳定、高质量地完成 PR，从而建立起可信赖的技术形象？

如何快速、高质量地完成PR

个人愚见，想要快速、高质量地完成PR 依赖三个因素：

1. 效率：效率决定了你能否在有限的时间内完成更多高质量的工作内容。意味着你可以更快进入Review 状态、及时响应 Review 意见、快速修复问题，从而缩短 PR 的生命周期，加快合并速度。
2. 质量：效率决定了你能否在有限的时间内完成更多高质量的工作内容。意味着你可以更快进入Review 状态、及时响应 Review 意见、快速修复问题，从而缩短 PR 的生命周期，加快合并速度。
3. 人脉：人脉是推动 PR 高效合并的重要保障。良好的社区关系有助于你在提交后快速获得反馈、避免长期搁置；在关键技术讨论或投票环节，也更容易争取到支持，为方案落地和个人发展提供助力。

具体方法

接下来，我将会介绍一下我个人的方法实践，主要围绕如下三个方面展开说明

1. 节奏、目标管理
2. 社区信任
3. 编码质量和效率

节奏、目标管理

并发任务处理

高效的任务并发处理能力是决定 PR 效率的关键。建议严格遵循“开发–Review–切换–跟进”的流水线机制，把每一个等待时间都转化为另一个 PR 的推进周期。

• 当一个 PR 进入 Review 阶段，我会立刻切换到另一个PR的开发任务；
• 每日规划任务视图，确保始终有一个PR在开发、一个或多个PR在等待反馈；
• 特别注意要保证精力、注意力集中，不能被上下文切换打碎，而是像 CPU 并发一样有序调度。

适应 Maintainer 的 Review 周期

由于 Maintainer 在一天之内只会在近似固定的时间段内审核代码，因此每天一个 PR 得到 Review 的次数也是近似固定的。所以我们必须精确计算提交时间和提交频率以抓住每一个审核机会。

这里举个例子：我负责的模块的 Maintainer 在湾区，北京时间比湾区快 15 个小时。这样一来，我每天实际上有两个关键的审核窗口：

• 第一个窗口在中午 12 点之前，此时是湾区的前一晚 9 点；
• 第二个窗口在晚上 11 点左右，对应湾区的当天早上 8 点。

假设 CI 跑完需要 1 小时，那么我必须在上午 11 点或晚上 11 点前完成修改并提交 PR。这样可以确保：

• 第一个审核窗口中，Reviewer 睡前能看到最新的修改；
• 第二个审核窗口中，Reviewer 上班后能继续跟进。

通过卡住这两个时间点，我可以最大化利用双方的时差，确保每轮修改都不会被延迟，提高整体的审核效率。这一点需要灵机应变，根据实际情况调整时间点，核心思想是：

• 合理安排提交时间：计算 CI 执行耗时，确保 CI 任务完成后再邀请 Reviewer，避免 Reviewer 查看时 CI 尚未通过，影响审核效率
• 推荐使用“@邀请 + 评论”结合的方式：在合适的节点通过 @Maintainer 搭配简要 Comment，引导 Reviewer 快速关注并响应，提高 Review 的响应速度
• 添加 PR Summary：编写清晰的 Commit 摘要与变更说明，并在评论中明确标注，有助于 Reviewer 更高效理解改动，提升通过率

不盲目刷 PR，质量优先

初期参与项目时，从简单或非核心功能入手，是一个比较合适的切入点，既可以熟悉项目结构，也有利于建立与社区的信任。但这种工作方式并不适合长期投入，想要更有价值的成长和影响力，应当逐步转向更具代表性和可见度的工作。围绕“多做一些可以写进 Release Note 的 PR”。对此，我有以下四点建议：

• 聚焦价值贡献：不要盲目刷 PR。零散、简单的改动堆积再多，也难以建立技术信任，反而可能给 PMC 留下“贡献浮于表面”的印象。
• 核心模块和关键问题优先：聚焦核心功能或关键问题的 PR 更容易被关注，不仅能显著提升自身能力，也更具长期影响力。
• 系统性贡献：系统性贡献往往能在 Release Note 中留下清晰痕迹，而碎片化的修改则难以体现出实际价值。
• 提升贡献的可见度：优先参与涉及架构、接口的 PR，这些改动影响面广，可以更好的让社区了解自身的技术能力，提高影响力。

社区信任

个人认为赢得社区的信任有三个维度

• 技术力（高质量 PR + 架构理解）
• 沟通力（响应及时、表达清晰）
• 规范意识（理解并践行社区规则）

接下来我将会出个介绍具体的方法实践

尊重规则

开源项目之所以能长期、稳定地演进，靠的并不只是个人英雄主义，而是整个社区基于信任、共识与规则的协作机制。而这些“规则”，正是从千万次实践中逐步沉淀出来的最佳协作方式。

对于希望深度参与社区的开发者来说，理解并遵循社区协作规则，远比写好一个 PR 更重要。它不仅体现了对他人劳动的尊重，也决定了你在社区中是否值得托付与协作。以下是我在参与 Apache 项目过程中，对社区规则的几点体会与建议：

• 明确工作边界：如果某个 Issue 已被明确分配（Assignee 已存在），请勿提交重复的 PR，除非获得原作者或模块 Maintainer 的同意，即使你已经完成了开发与测试，也应尊重他人优先权。
• 规范处理 Comment 与反馈：他人提出的评论（Comment）不应由自己直接点击 Resolve。应当在修复后主动回复 Fix 或类似说明；若存在异议，应在评论中清晰阐明理由，避免评论项悬空或无反馈。
• 理解并践行 Apache Way：Apache 社区在依赖管理、文档编写等方面有明确约定：例如引入新依赖时需补充 LICENSE.bin 和 NOTICE 文件，并确保其开源协议兼容。

避免低级错误

除了协作流程与社区规则，提交代码本身的质量与规范性，同样是衡量一个开发者是否值得信任的重要标准。有些低级错误，在实践过程中一定要避免：

• 只通过 UT 测试提交的风险：仅依赖 UT 测试并不全面，UT 测试未必会触发 RAT 检查。若有文件遗漏协议声明或协议错误，UT 测试无法发现，但 CI 流程中会报 rat Task Error，影响效率。
• 避免无意义的注释：注释应简洁明了，专注于方法和类的功能说明。避免添加冗余的细节注释，尤其是对那些逻辑简单、易于理解的代码部分，过多注释反而影响代码可读性。
• 避免常识性问题：指的是那些本应通过基础知识规避、或通过简单验证即可发现的问题。它们通常不是因为技术难，而是因为对规范、细节或流程的忽视。在一个 PR 中反复出现此类问题，会直接影响 PMC 或 Reviewer 对开发者技术能力与工程素养的判断。一旦这种信任被削弱，后续的代码审核与合并将变得困难。
• 避免犯相同的错误：每一条 Review 意见，都是一次优化代码的机会，如果在后续提交中反复出现相同的问题，不仅说明对反馈不重视，也会逐渐削弱 Reviewer 或 PMC 对你的技术信任。

降低 Reviewer 负担

在开源协作中，PR 的质量不仅体现在代码本身，更体现在对 Reviewer 体验的考虑上。一个清晰、精炼、意图明确的 PR，能极大降低沟通成本，加快合并效率，也体现了开发者的工程素养。特别是在高并发、多 PR 并行评审的社区中，越是能够主动“为 Reviewer 多想一步”，越容易赢得尊重与信任。以下是几条我在实践中总结的、用于降低 Reviewer 负担的建议：

• 遵循奥卡姆剃刀原则：在设计类和接口时，应坚持精简且高效的结构。避免不必要的抽象、继承或包装，每一个新增的类、接口或层次都必须具有清晰的职责与不可替代的价值。冗余的设计不仅会增加系统复杂度、削弱可读性，还会导致维护成本上升、后续演化受限，同时也会影响 Reviewer 的理解效率与评审判断。
• 使用明确语义的代码：代码的首要目标是表达意图。凡是能提升语义清晰度的封装，都是值得的。哪怕引入额外结构或类型包装，只要能准确传达业务约束、减少误解与误用，就比追求“看起来简单”的实现更具长期价值。语义的明确性应优先于代码的形式简洁。

编码质量和效率

AI 辅助编程

使用 AI 辅助编程已经是老生常谈，我这里给出一点个人的见解：

• 代码补全：利用 IDE 智能补全插件或 AI 工具（cursor、trae CN）可快速补全方法体、调用链与模板代码，提升编码效率
• 注释生成：通过 AI 工具或插件自动生成方法注释、类注释及参数说明，统一注释风格，降低文档维护成本
• 基于图片的操作能力：AI 应具备理解并解析截图、架构图等图像信息的能力，从而支持“看图写代码”、自动化生成结构或执行相关操作，突破仅依赖文字输入的限制。

就个人而言，一个优秀的大模型应具备以下能力，以更好支撑多场景、高质量的智能生成与交互体验：

1. 支持图像驱动的理解与操作：具备图像识别与上下文联动能力，能根据截图、架构图、报错提示等进行分析与操作建议。
2. 支持 Markdown 输入与输出：兼容结构化内容格式，便于技术写作、笔记整理、交互内容嵌套与复用。
3. 支持多种文档格式导出：可将内容高质量地输出为 PDF、Word（.docx）、Markdown、HTML 等，满足开发文档、汇报材料、正式稿件等多种交付场景。
4. 支持网页渲染与结果直达：具备将结果以网页形式展示的能力，适配图表、表格、交互按钮等，提升可视化与交付效率。
5. 支持代码执行与调试辅助：能识别并运行代码片段，结合解释与推荐，提供调试建议，辅助学习和开发

注意代码细节

• 严格按照字典序：模块内部新增依赖、常量定义等应严格按照字典序排列。
• 多用工具类：面对通用逻辑，应优先封装为工具类统一复用，避免 copy-paste 或多处隐式逻辑演变，增强代码一致性与可维护性。
• 排除测试依赖：当引入如 JMH、JCStress 等仅用于测试的依赖时，应在构建配置中显式排除其相关 JAR，确保它们不会被打包进最终发布物中，避免引入无关依赖，影响运行环境的纯净性。
• 合理使用判断方法的返回值：许多判断类方法本身具备返回值，调用后可直接参与条件判断，无需额外封装或多余判断。保持调用链简洁有助于提升代码可读性与表达力。
• 谨慎使用 Mockito：尽量减少在测试中对 Mockito 的依赖，尤其是长期大规模使用，可能带来以下问题：
  • 初期实现简单，长期维护成本高；
  • 默认返回值（null、0、false）易导致 隐蔽性 BUG；
  • 使用 mockedStatic 时，若测试类使用 PER_CLASS 生命周期，极易导致状态污染与执行异常。

记录、思考和优化

• 问题记录：将开发过程中遇到的问题与规范系统性沉淀为文档，构建个人 checklist，用于日常开发中的自检与校准，逐步形成稳健的编码习惯。
• 成果记录：通过图表、表格等可视化方式，按时间维度量化工作成果，借助客观指标评估进步，避免主观判断。
• 定期复盘：每周进行复盘，结合量化数据识别效率瓶颈与常见错误，针对性优化方法与节奏，持续提升下阶段工作表现。
• 优化工作流：基于问题与复盘结果迭代工作流，实现从“发现问题”到“持续优化”的闭环。

这里简单介绍一下我的工作流：

首先，我会系统地记录所有维度的个人信息，包括工作成果、社区贡献、身体状态等，为后续分析与复盘提供真实依据。

其次，每周我都会进行定期复盘，内容涵盖编码时间、贡献情况与身体状态等。推荐使用 WakaTime 来量化每周 Coding 投入，帮助识别精力分布与节奏失衡。

再次，借助飞书自动化能力，我实现了任务推送、每日填写、数据归档与指标计算的闭环自动化，大大降低了执行成本。

最后，这些数据会汇聚到我的个人仪表盘中，用于全方位衡量工作效率、社区参与度与健康状况。通过周期性对比，我可以清晰识别出哪些指标出现波动，并及时进行调整与干预。

我始终相信：指标好不一定代表进步；但指标差，几乎一定意味着退步。

时间节点参考

1. 2024-12.6：🎯 第一个 PR 提交
2. 1 月～3 月：CLI 开发
3. 3 月～4 月：完成事件系统 EPIC（Core 模块）
4. 4 月～5 月：实现 Model / Model Version 更新功能（Core 模块）
5. 5 月～7 月：元数据鉴权 + 缓存开发（独立 Feature）
6. 2025.07.03：🎉 正式成为 Apache Committer

个人开源感悟

这段开源旅程，带给我的远不止技术的成长或 Committer 的头衔。真正改变我的是三个关于人生的重要体悟。

身体是第一生产力

身体是第一生产力，如果健康垮了，再多的努力也可能付诸东流。根据 WakaTime 的统计，过去半年我在 Gravitino 项目的编程时间累计接近 500 小时，平均每周 coding 时间维持在 35～40 小时。这种高强度的节奏，长期来看，对身体的负担是显而易见的。

长时间的高压工作、运动减少，加之免疫力下降，身体最终敲响了警钟。比如就在上周，我突发急性鼻炎，眼眶神经疼痛难忍，导致注意力无法集中，工作效率骤降。这次经历让我深刻意识到：健康并不是“加分项”，而是一切努力的前提条件。

人生不是百米冲刺，而是一场需要节奏、耐力与恢复能力的马拉松。持续处于高压状态，只会透支身体、积累情绪、反噬效率。唯有长期保持良好的身体与精神状态，才能走得更稳、走得更远。这不仅是对自己负责，更是对团队与项目负责任的态度。

努力是成功的必要前提，但非充分条件

努力是成功的必要条件，但远非决定性因素。就拿我参与的 Gravitino 项目来说——如果没有各位领导的信任与支持，我或许根本没有机会参与，也不可能投入如此多的精力深入其中；如果没有社区老师们几乎实时的答疑与 Code Review，我也不可能在短时间内实现快速成长并获得认可。

正所谓千里马常有，而伯乐不常有。我亲眼见过许多优秀的 PR 因缺乏响应和支持而长期滞留，甚至最终被他人重新实现（其中一部分我也亲自接手过）；也看到不少开发者持续耕耘，却因为种种原因，始终没能获得应有的认可。

所以，是否最终“成事”，从来不是由个人努力单方面决定的。机会、环境、协作、信任，缺一不可。但无论结果如何，过程中所经历的成长与积累，始终是属于自己、无可替代的回报。

珍惜每一次机会

既然努力与成功之间并非绝对因果，我们就更应珍惜那些稍纵即逝的机会。

以此次参与 Gravitino 项目为例——它正值早期开源阶段，功能尚待完善，设计空间广阔；项目又恰逢加入 Apache 孵化器并顺利毕业为顶级项目，具备良好的社区治理与成长潜力。更幸运的是，公司正积极探索相关方向，使我所投入的时间与精力，不仅有社区价值，也有实际落地意义。

现实中，像这样的机遇实属难得。多个关键因素的汇聚，才造就了这段宝贵的成长经历。愿我们都能把握人生中每一个可能，在热爱的道路上坚定前行！