code.gitea.io/gitea@v1.22.3/docs/content/contributing/guidelines-refactoring.zh-cn.md (about)

     1  ---
     2  date: "2023-05-25T00:00:00+00:00"
     3  title: "重构指南"
     4  slug: "guidelines-refactoring"
     5  sidebar_position: 20
     6  toc: false
     7  draft: false
     8  aliases:
     9    - /zh-cn/guidelines-refactoring
    10  menu:
    11    sidebar:
    12      parent: "contributing"
    13      name: "重构指南"
    14      sidebar_position: 20
    15      identifier: "guidelines-refactoring"
    16  ---
    17  
    18  # 重构指南
    19  
    20  ## 背景
    21  
    22  自2014年2月12日编写了第一行代码以来，Gitea已经发展成为一个庞大的项目。
    23  因此，代码库变得越来越大。代码库越大，维护就越困难。
    24  存在许多过时的机制，许多框架混合在一起，一些遗留代码可能会导致错误并阻碍新功能的开发。
    25  为了使代码库更易于维护，使Gitea变得更好，开发人员应牢记使用现代机制来重构旧代码。
    26  
    27  本文档是关于重构代码库的指南集合。
    28  
    29  ## 重构建议
    30  
    31  * 设计更多关于未来的内容，而不仅仅解决当前问题。
    32  * 减少模糊性，减少冲突，提高可维护性。
    33  * 描述重构，例如：
    34    * 为什么需要重构。
    35    * 如何解决旧问题。
    36    * 重构的优点/缺点是什么。
    37  * 只做必要的更改，尽量保留旧逻辑。
    38  * 引入一些中间步骤，使重构更容易审查，完整的重构计划可以在几个PR中完成。
    39  * 如果存在分歧，应该请TOC（技术监督委员会）参与决策。
    40  * 添加必要的测试以确保重构的正确性。
    41  * 非错误重构优先在里程碑的开始时进行，这样可以更容易地在发布之前发现问题。
    42  
    43  ## 审查和合并建议
    44  
    45  * 重构的PR不应该长时间保持打开状态（通常为7天），应尽快进行审查。
    46  * 重构的PR应尽快合并，不应被其他PR阻塞。
    47  * 如果TOC没有异议，重构的PR可以在7天后由一名核心成员（非作者）批准后合并。
    48  * 如果最终结果良好，容忍一些不完美/临时的步骤。
    49  * 如果重构是必要的，容忍一些回归错误，并尽快修复错误。