forgejo/docs/content/contributing/guidelines-refactoring.zh-cn.md
John Olheiser b217ce3e9f
Docusaurus-ify 1.20 (#26052)
See https://github.com/go-gitea/gitea/pull/26051

---------

Signed-off-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: JonRB <4564448+eeyrjmr@users.noreply.github.com>
(cherry picked from commit 4033d95dbf)
2023-07-26 13:49:16 +02:00

1.9 KiB
Raw Blame History

date title slug sidebar_position toc draft aliases menu
2023-05-25T00:00:00+00:00 重构指南 guidelines-refactoring 20 false false
/zh-cn/guidelines-refactoring
sidebar
parent name sidebar_position identifier
contributing 重构指南 20 guidelines-refactoring

重构指南

背景

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

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

重构建议

  • 设计更多关于未来的内容,而不仅仅解决当前问题。
  • 减少模糊性,减少冲突,提高可维护性。
  • 描述重构,例如:
    • 为什么需要重构。
    • 如何解决旧问题。
    • 重构的优点/缺点是什么。
  • 只做必要的更改,尽量保留旧逻辑。
  • 引入一些中间步骤使重构更容易审查完整的重构计划可以在几个PR中完成。
  • 如果存在分歧应该请TOC技术监督委员会参与决策。
  • 添加必要的测试以确保重构的正确性。
  • 非错误重构优先在里程碑的开始时进行,这样可以更容易地在发布之前发现问题。

审查和合并建议

  • 重构的PR不应该长时间保持打开状态通常为7天应尽快进行审查。
  • 重构的PR应尽快合并不应被其他PR阻塞。
  • 如果TOC没有异议重构的PR可以在7天后由一名核心成员非作者批准后合并。
  • 如果最终结果良好,容忍一些不完美/临时的步骤。
  • 如果重构是必要的,容忍一些回归错误,并尽快修复错误。