如何在开源项目中做重构？

最近完成了 Databend 存储模块的大重构，在不阻塞现有功能开发的前提下，基本无痛的完成了功能的实现。本文总结了我个人的一些经验，期望能够带来一些启发。编程学习资料点击免费领取​​​​​​​

做重构不易，尤其是在一个相当活跃的 codebase 上。Databend 现在每周有 40+ PR 被 merge，在过去的一周中有 800+ 文件发生了变更，代码增加了 21K 行，删除了 12K 行。在这样的代码库上，毕全功于一役的代价是高到可怕的。所以在整个重构的生命周期中，我们都需要跟社区保持密切沟通，让社区知道你想做什么，怎么做，现在的进展如何。在这一次的重构中我总结出了如下经验：

撰写提案

正如 The Apache Way 所说：Community over code。一个好的开源项目不仅仅是由代码组成，抛开开源共同体谈抽象的技术和代码是没有意义的。因此向开源项目提交大型的变更之前，我们必须要阐述清楚自己的想法，解释动机，让开源共同体知道自己想做什么，想怎么做。

这些落到纸面上的文档在讨论时能够补充信息，完善想法，构建出更好的设计。从长期角度看，文档能够帮助后来者理解当时为什么要提出这样的设计，从而避免重复踩坑。不仅如此，一份好的设计文档往往还能够影响、启发其他开源项目的设计，从而促进整个行业进步。

对于任何 non-trivial 的改动，都需要有一定的描述来表明动机；对于大的改动，更需要设计文档来留存记忆。人的记忆不是永久的，总会忘记最初的时候自己为什么做某一件事情，设计文档的沉淀对于社区摆脱人的不确定性演化有至关重要的作用。

在本次重构之前，跟多位相关的模块的维护者取得了沟通，达成了广泛的一致意见，之后才开始了本次的重构。我认为跟维护者取得一致是非常关键的步骤，否则极有可能出现工作到一半时维护者发现想法冲突导致工作被终止或者重来，这是非常沮丧的。

此外，开源共同体本质上都在奉行基于开源贡献的精英主义原则。贡献者必须要通过贡献来证明自己的价

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！