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

  • auto-comment:contributor 提出 issue 或者 pr 后 , 可很方便地发出预先定制的评语;
  • hound:一个 Go 语言项目静态代码检测工具 , 自动 Review 代码;
  • travis:一个 Github 项目自动化测试工具 , 可自动执行代码单测和用户自定义的集成测试 , 并发出钉钉通知;
  • 人工 Review:dubbogo 社区要求每个 pr 至少有三个 committer 级别的人 Review 通过;
  • goreportcard:一个很好的 Github 项目静态代码检测工具;
  • gitee:作为国内一个比较强大的代码托管网站 , 免费为项目提供了一些代码安全和静态代码质量检测工具 , dubbogo 也经常使用 , 受益良多;
  • 代码规范 , 社区内部有一份简单的代码规范 , 并随着项目发展不断完善 。
展望
dubbogo 项目每次发完版本 , 发版人都会首先发出一份 ''What's New'' , 除了总结最新版本的特性外 , 还会总结其近期进展并对未来发展进行规划 , 以帮助项目爱好者和使用者了解其实现思路和使用方法 。
dubbogo 自身还有很多缺点 , 如: