重构指南

背景

自 2014 年 2 月 12 日编写第一行代码以来，Gitea 已经发展成为一个大型项目。因此，代码库也变得越来越大。代码库越大，维护难度就越大。许多过时的机制仍然存在，许多框架混合在一起，一些遗留代码可能导致 bug 并阻碍新功能的开发。为了使代码库更易于维护，并使 Gitea 变得更好，开发人员应该牢记使用现代机制来重构旧代码。

本文档是重构代码库的指南集合。

重构建议

• 更多地考虑未来设计，而不仅仅是解决当前问题。
• 减少歧义，减少冲突，提高可维护性。
• 描述重构，例如
  • 为什么需要重构。
  • 如何解决遗留问题。
  • 重构的优缺点是什么。
• 只进行必要的更改，尽可能保留旧逻辑。
• 引入一些中间步骤，使重构更容易审查，完整的重构计划可以在多个 PR 中完成。
• 如果有任何分歧，应邀请 TOC（技术监督委员会）参与帮助做出决策。
• 添加必要的测试以确保重构正确。
• 非 bug 修复的重构最好在里程碑开始时进行，这可以更容易地在发布前发现问题。

审查和合并建议

• 重构 PR 不应该长时间保持打开状态（通常为 7 天），应该尽快进行审查。
• 重构 PR 应该尽快合并，不应该被其他 PR 阻塞。
• 如果没有 TOC 的反对意见，重构 PR 在 7 天后即可合并，需要一位核心成员（非作者）批准。
• 如果最终结果良好，则可以容忍一些脏/hacky 的中间步骤。
• 如果重构是必要的，则可以容忍一些回归错误，并尽快修复错误。