---
date: "2023-02-14T00:00:00+00:00"
slug: "guidelines-refactoring"
sidebar_position: 40
aliases:
  - /zh-tw/guidelines-refactoring
---

# 重構指南

## 背景

自 2014 年 2 月 12 日編寫第一行代碼以來，Gitea 已經成長為一個大型項目。
因此，代碼庫變得越來越大。代碼庫越大，維護起來就越困難。
存在許多過時的機制，許多框架混合在一起，一些遺留代碼可能會導致錯誤並阻礙新功能。
為了使代碼庫更易於維護並使 Gitea 更好，開發人員應牢記使用現代機制來重構舊代碼。

本文檔是重構代碼庫的指南集合。

## 重構建議

- 更多地考慮未來，而不僅僅解決當前問題。
- 減少模糊性，減少衝突，提高可維護性。
- 描述重構，例如：
  - 為什麼需要重構。
  - 如何解決遺留問題。
  - 重構的優缺點。
- 僅進行必要的更改，盡可能保持舊邏輯。
- 引入一些中間步驟，使重構更易於審查，完整的重構計劃可以在幾個 PR 中完成。
- 如果存在分歧，應邀請 TOC（技術監督委員會）幫助做出決定。
- 添加必要的測試以確保重構正確。
- 非錯誤重構優先在里程碑的開始進行，這樣在發布之前更容易發現問題。

## 審查和合併建議

- 重構 PR 不應長時間保持打開狀態（通常為 7 天），應盡快審查。
- 重構 PR 應盡快合併，不應被其他 PR 阻塞。
- 如果 TOC 沒有異議，重構 PR 可以在 7 天後由一名核心成員批准（非作者）後合併。
- 容忍一些臟/臨時的中間步驟，如果最終結果是好的。
- 如果重構是必要的，容忍一些回歸錯誤，並盡快修復錯誤。
