mirror of
https://gitea.com/gitea/docs.git
synced 2026-07-11 21:42:12 +00:00
965c269495
--------- Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: silverwind <2021+silverwind@noreply.gitea.com> Reviewed-on: https://gitea.com/gitea/docs/pulls/455 Reviewed-by: silverwind <2021+silverwind@noreply.gitea.com>
41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
---
|
||
date: "2023-05-25T00:00:00+00:00"
|
||
slug: "guidelines-refactoring"
|
||
sidebar_position: 20
|
||
aliases:
|
||
- /zh-tw/guidelines-refactoring
|
||
---
|
||
|
||
# 重構指南
|
||
|
||
## 背景
|
||
|
||
自 2014 年 2 月 12 日編寫了第一行程式碼以來，Gitea 已經發展成為一個龐大的專案。
|
||
因此，程式碼庫變得越來越大。程式碼庫越大，維護就越困難。
|
||
存在許多過時的機制，許多框架混合在一起，一些遺留程式碼可能會導致錯誤並阻礙新功能的開發。
|
||
為了使程式碼庫更易於維護，使 Gitea 變得更好，開發人員應牢記使用現代機制來重構舊程式碼。
|
||
|
||
本文件是關於重構程式碼庫的指南集合。
|
||
|
||
## 重構建議
|
||
|
||
- 設計更多關於未來的內容，而不僅僅解決當前問題。
|
||
- 減少模糊性，減少衝突，提高可維護性。
|
||
- 描述重構，例如：
|
||
- 為什麼需要重構。
|
||
- 如何解決舊問題。
|
||
- 重構的優點/缺點是什麼。
|
||
- 只做必要的更改，儘量保留舊邏輯。
|
||
- 引入一些中間步驟，使重構更容易審查，完整的重構計劃可以在幾個 PR 中完成。
|
||
- 如果存在分歧，應該請 TOC（技術監督委員會）參與決策。
|
||
- 添加必要的測試以確保重構的正確性。
|
||
- 非錯誤重構優先在里程碑的開始時進行，這樣可以更容易地在發佈之前發現問題。
|
||
|
||
## 審查和合併建議
|
||
|
||
- 重構的 PR 不應該長時間保持打開狀態（通常為 7 天），應儘快進行審查。
|
||
- 重構的 PR 應儘快合併，不應被其他 PR 阻塞。
|
||
- 如果 TOC 沒有異議，重構的 PR 可以在 7 天后由一名核心成員（非作者）批准後合併。
|
||
- 如果最終結果良好，容忍一些不完美/臨時的步驟。
|
||
- 如果重構是必要的，容忍一些迴歸錯誤，並儘快修復錯誤。
|