维护 react-beautiful-dnd 的成本是多少？
本博客旨在公开维护开源拖放项目react-beautiful-dnd（rbd）所需的持续努力。该项目的维护方式rbd与其他开源项目有所不同，但我认为仍然具有一定的参考价值。通过公开维护信息，我希望能够打破“开源项目比私有项目更省力”的迷思。开源项目的确有很多优势，但维护成本并非其中之一。
rbd非常受欢迎，深受喜爱❤️
我很幸运能在Atlassian全职参与这个rbd项目近两年，并且是它的主要维护者。该项目在公司内部（例如 Jira Software、Jira Portfolio、Jira Service Desk、Trello 和 Confluence 等）和外部（例如 Facebook、Box、Zendesk 等）均被广泛使用。它目前已跻身最受欢迎项目前 20 名，也是网络上下载量最高的拖放式软件包之一。该软件包一直以来都为 Atlassian 赢得赞誉。rbd React
最好的防守就是进攻🏈
优化自助服务
我已采取一系列策略，旨在最大限度地提高用户上手rbd、使用rbd和解决问题的能力，而无需直接联系客服（自助服务）。这些策略包括：
- 创建了一个免费的
egghead.io快速入门课程，一步一步地指导人们如何开始使用图书馆。 - 创建并维护大量文档
- 仅
console针对可检测到的安装问题添加开发警告。这样，用户在遇到大多数安装问题时就不需要查阅文档了。 - 创建常见安装问题指南
- 创建问题模板，帮助用户在寻求帮助之前自行调试问题。
- 将反复出现的问题作为文档不清晰或仅供开发使用的良好警告的信号
没有未解决的漏洞🐛❌
我采取了一种相当大胆的做法rbd：只要还有未解决的 bug，我就不会发布任何新功能。这听起来似乎难以实现，但rbd这种策略我已经成功运用了近两年。通过保持高质量标准，我减少了用户反馈的需求，也降低了我维护所需的时间。
吐槽🌶
很难判断一个 bug 是无关紧要的小问题，还是暴露了根本性的问题。为了自信地推进软件项目，我们需要确保我们所构建的基础架构稳固可靠——否则，我们将陷入无休止的修复和返工之中。用户使用一个项目时，希望它能够正常运行。项目存在一些局限性是可以接受的，但如果无法实现其宣称的功能，就会严重损害用户的信任。
工作量👷♂️
我之前提到过，我做了很多工作来推广自助服务rbd。然而，人们仍然会出于各种原因联系我。这些加起来平均每周需要花费一天的时间。每周的工作量都会有所波动。
错误报告🐛
我大约每1-2天会收到一份错误报告。错误报告有几种类型：
- 幽灵问题：创建的问题缺乏详细信息或示例。我要求提供更多信息和演示（我提供了一个模板演示）。之后便杳无音信。过一段时间后，我不得不手动关闭该问题。我告知他们，如果他们提供更多信息，可以重新打开该问题。
- 简单的设置问题：有些问题只需让用户查看控制台（控制台可能已经显示了问题所在以及如何解决），或者让他们参考我们的文档即可解决。很多这类问题都来自刚开始使用软件
React或rbd正在进行早期项目的用户。因此，用户常常遇到的是一些React问题，而不是软件rbd本身的问题。 - 复杂的配置问题：有时，人们发布的复杂示例中会出现类似 bug 的行为。经过大量调查，我发现答案其实是一个简单的配置问题，它被层层复杂性所掩盖。
- 遇到限制：用户遇到了库中已记录的限制。需要解释该限制，并提供任何相关的问题或文档链接。有时，这可能会导致添加新的功能请求，或者为现有的功能请求添加更多细节。
- 实际的 bug：实际的 bug 会被提出并需要修复。我需要诊断 bug，进行根本原因分析，设计解决方案，编写修复程序，编写测试，合并修复程序并发布新版本。有些 bug 很简单，修复方法显而易见。有些 bug 则会暴露更深层次的问题。如果我知道正确的修复需要花费更多精力，我会先发布一个短期的临时解决方案。我会在本地环境中重现提供的示例 bug，以便进行开发
rbd。有时一个 bug 可能只需一个小时就能修复，有时则需要两天。有时它需要对架构进行更改，而这可能需要几个月的时间才能完成。
设置和限制问题也可能导致文档和开发方面的改进，而这些改进可能仅仅是为了提供警告。理想情况下，我们应该尽可能地让用户清楚地了解所有问题。我会将重复出现的问题视为一个信号。
功能请求🚀
rbd我们会收到大量交互功能请求。这些请求需要经过我们的指导原则审核和评估。有时我认为某个请求符合库的发展方向，因此会保留该请求。这或许会开启一场讨论，让我们一起探讨该功能的意义和实现细节。而有时，该请求与项目方向不符，我会给出解释并关闭该请求。我可能还会将这些信息添加到项目理念页面中。
讨论🗣
我们同时开通了多个讨论帖，专门讨论那些还需要进一步思考的功能和想法。这些讨论帖可能会涉及冗长的来回辩论，以及 API、用例、实现、测试和潜在影响等问题。我经常会在洗澡的时候（或者洗澡的时候）思考这些问题。
拉取请求
我们每周大约会收到一个项目拉取请求rbd。这些请求分为多个类别。
- 文档修复：几乎总是可以轻松合并
- 建议的代码变更：要么是错误修复，要么是新功能。很少创建，合并的更是少之又少。
建议的代码变更
团队React委婉地表示，他们很少接受外部贡献者的修改。该React项目历史悠久，发展方向明确。外人很难对核心库做出有意义的贡献。我发现其他项目也是如此rbd。我们欢迎并鼓励对项目边缘进行修改，例如文档、构建改进、类型定义、示例以及（小的）错误修复。但外部贡献者通常缺乏进行重大修改所需的背景知识。我们偶尔会收到一些修改，但他们往往试图实现自身目标，而没有从更广泛的角度考虑库的整体情况。我发现这些修改提议通常与项目的可访问性或理念相冲突。我通常鼓励大家在进行大规模工程工作之前先与我们联系，讨论修改应该采取何种方法：
- 技巧：利用现有或新的 API 来实现其用例
- 分支：维护一个分支版本，其中包含其行为
- 贡献：
rbd可能需要这个功能。就我的经验而言，我们还没有遇到过完全由外部人员贡献的功能。有时我可以指导他们修复 bug。另一个挑战是他们的技能水平。有好几次，我需要重写外部人员提交的 pull request 中的大部分内容。
主持人👩⚖️
目前有 50 多个活跃问题rbd。这些问题包括功能请求、讨论、改进建议和想法。我会关注这些问题，提供反馈并确保行为准则得到遵守。我尽量在 48 小时内回复用户。此外，我还需要关闭一些旧的或重复的问题。我偶尔也会收到来自 Twitter、Stack Overflow 和其他渠道的提问。如果问题很简单，我会直接回答；如果比较复杂，我会引导用户到项目页面创建问题。
分享🎁
这个项目包含一些非常有趣的工程技术rbd。我通过撰写博客和发表演讲来分享我的学习心得并推广这个rbd项目。通过这些方式，项目的影响力rbd远不止于项目本身。我通常会花半天到两天的时间写一篇博客，半天到一天的时间准备在聚会上发言，三到五天的时间准备会议演讲。在创作可分享的内容之前，我还会进行大量的思考、探索和讨论。
项目相关博客
绩效相关的博客
分享一些我在性能工程方面的经验rbd
会谈
- 使用 React Hooks 进行深海钓鱼
- 为 Atlassian 创建美观易用的拖放功能
- 从头开始进行速率限制
- 盒子里装的是什么？
- React Portal：优点、缺点和不足之处
- 推动 React 性能向前发展
- React性能优化：第二轮
- React 应用程序的性能优化
- React性能优化
- 在 Atlassian 内部前端交流会上，有 30 多人参加。
Atlassian内部维护
所有的问题跟踪和讨论rbd都在 GitHub 上进行，因此大多数情况下，内部问题无需重复更新。但是，rbd也存在一些内部任务，包括：创建和更新项目高级跟踪问题、与内部利益相关者会面讨论未来需求、撰写内部博客以及进行规划讨论。
结语
维护工作rbd 需要持续投入大量精力。维护如此规模的项目固然令人愉悦，但也十分繁重。积极推行自助服务并持续参与项目，使维护工作变得更加轻松。我知道，在我需要专注于其他事务的时候，项目的维护工作必然会有所疏忽，因为要全面掌控这个项目确实是一项艰巨的任务。
希望您觉得这篇关于维护成本的文章对您有所帮助rbd。也非常感谢 Atlassian 一直以来允许我进行投资rbd✌️