写在 Dubbo go 的第五年( 三 )

至于 dubbo-go-proxy， dubbogo 社区并不打算借鉴其他项目，完全依靠社区同学贡献各自想法后，进行项目需求收集。目前 dubbogo 社区已经收集完毕 dubbo-go-proxy 的项目需求方的意见，社区已有 5 位同学参与项目一期开发，预计 10 月份发布初版。
2. 项目管理
需求收集完毕，定义近期一段时间内的开发目标后，就进入了项目任务拆解和项目开发管理阶段。像 dubbogo 和 dubbo-go-proxy 这种后来者项目，处于追赶阶段，个人理解它们并没有所谓的后发优势，更没有特定的技术优势，能够做的就是快速迭代，缩短与竞品的差距。
dubbogo 要求接受开发任务的各个 feature owner 必须在某个 deadline 前完成相应的开发任务。当然， feature 的等级不同，非核心 feature 【如技术预演性的 feature】允许 delay ，顺延发布也无不可。
我们在项目每个版本的需求收集阶段，会把爱好者统一拉入一个小群进行沟通交流。进入开发阶段时，由于项目时间 deadline 限定以及技术匹配度两项要求，每个版本就很自然能选出能够留下来参与项目开发的人。最终参与每个版本开发的人尽量不要超过 7 个人，否则沟通成本就会剧增。
下图是 dubbogo v1.5.1 的项目管理图

本文插图
其有任务分解、技术风险以及风险预案。

本文插图
工具是生产力，目前以 dubbogo 项目开发进度跟踪工具使用 Github Projects 。如上图，每个子任务进度，这个工具都会及时显示，相应的任务 owner 可以及时根据任务进度和 deadline，调整开发计划。更进一步的好处是，没有人会对工具产生意见，摆脱“交通基本靠走，通讯基本靠吼”的沟通模式，减少版本发版人和 feature owner 之间的戾气。
3. 代码质量
开源项目的开发任务不仅仅是开发代码，也不意味着因为各个 owner 仅仅是业余时间参与开源项目就可以降低对代码质量要求。
工具就是生产力，合适的工具能够减少人工工作量和提升代码质量。 dubbogo 在项目开发过程中的各个阶段都用到了如下工具：