第一个开源issue复盘:从前端破防到真正能开发

type

Post

status

Published

date

Mar 8, 2026

slug

firstissue

summary

category

icon

password

这是我接的第一个开源issue,从自己写玩具项目,到联调,到真正学会开发,这次经历中我得到了长足的进步.

issue地址:

[Refactor] Refactor the List and Detail http interfaces of the Service · Issue #1430 · apache/dubbo-admin

中文版本背景目前服务的list接口会返回providerAppName，这是因为目前list接口搜索的是ServiceProviderMetadata，一个ServiceProviderMetadata与providerAppName是一一对应的且必须要有providerAppName才能找到对应的ServiceProviderMetadata。但从dubbo领域模型的角度来看，一个服务...

https://github.com/apache/dubbo-admin/issues/1430#issuecomment-4062499347

PR已合并,我是co-author.

尽管我在2月初就加入了社区,但是最初一个多月我都在学习Dubbo

这个RPC框架可真不简单,尽管AI这么发达,可以全权交由ai来做.但我的理念就是把这个代码原理看明白了才去做这个功能开发.

不花时间,很难搞清楚这一套代码里面核心的功能是什么?一次RPC是怎么流动的,经过路径是什么?引擎如何设计的?数据又是怎么流动的?最难的地方还是怎么把各个模块的功能在脑海里面串起来

在沉淀了一个多月后我才在周会上接下了第一个issue,只是两个接口重构,看着很简单但是我也遇到了很多问题

复盘经验:

学会沟通!

1.拿到了一个模糊的任务,先跟需求提供者对清楚细节、边界

原本我已经根据issue描述做完了任务,但是就在做完的当天晚上项目负责人更新了具体改造点,完发现我的想法跟他要求的具体内容有挺大差别的,被迫重来一遍

2.联调搞清楚上下文,大胆问,沟通清楚

那两个接口的重构前后端都是我做.此外还有一位前端一位后端,我们仨一起实现一个大的服务拓扑任务.由于项目负责人说前端那边需要我的逻辑修改前端,就让我从前端的分支切出来实现,完事再 git cherry pick过去,但是在和前端沟通时候我没理解他的意思,其实是让我在另一位后端大哥的分支上做,我一直代入的负责人的逻辑,一直做一直出问题,都把前端整破防了哈哈

3.用好图形化界面开发,AI写的代码提交前严格自己review

这点还真给我省下好多麻烦,自那以后每次提交我都认真看,真多次发现AI做了无关改动,差点把不是我任务范围的修改也提交上去了

收获最大的是另一位后端大佬,他开腾讯会议,远程控我电脑,手把手教我分析、开发、抓包看、联调、复杂的团队git操作……两个小时三十多分钟,在这之后我才真正成长为了一名合格的开发者,能熟练开发而不是频繁出问题,不是只会AI写AI review的水货了

真是受了命运的眷顾,那还说啥了,传好运!