mirror
/
gitea
mirror of https://github.com/go-gitea/gitea
2
0
Fork 0
Code Issues Releases Wiki Activity
Git with a cup of tea, painless self-hosted git service Mirror for internal git.with.parts use https://git.with.parts
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
16501 Commits
17 Branches
214 Tags
5.0 GiB
Tag: Branch: Tree: e6d8b14620
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'e6d8b14620'
${ noResults }
gitea/docs/content/contributing/guidelines-refactoring.en-u...

50 lines
2.3 KiB
Raw Normal View History Unescape

Add some guidelines for refactoring (#22880) Just some brief ideas. Feel free to complete these guidelines, feel free to edit on this PR directly.
2 years ago
---
date: "2023-02-14T00:00:00+00:00"
title: "Guidelines for Refactoring"
slug: "guidelines-refactoring"
Docusaurus-ify (#26051) This PR cleans up the docs in a way to make them simpler to ingest by our [docs repo](https://gitea.com/gitea/gitea-docusaurus). 1. It includes all of the sed invocations our ingestion did, removing the need to do it at build time. 2. It replaces the shortcode variable replacement method with `@variable@` style, simply for easier sed invocations when required. 3. It removes unused files and moves the docs up a level as cleanup. --------- Signed-off-by: jolheiser <john.olheiser@gmail.com>
1 year ago
sidebar_position: 40
Add some guidelines for refactoring (#22880) Just some brief ideas. Feel free to complete these guidelines, feel free to edit on this PR directly.
2 years ago
toc: false
draft: false
Refactor docs (#23752) This was intended to be a small followup for https://github.com/go-gitea/gitea/pull/23712, but...here we are. 1. Our docs currently use `slug` as the entire URL, which makes refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712). Instead, this PR attempts to make future refactoring easier by using slugs as an extension of the section. (Hugo terminology) - What the above boils down to is this PR attempts to use directory organization as URL management. e.g. `usage/comparison.en-us.md` -> `en-us/usage/comparison/`, `usage/packages/overview.en-us.md` -> `en-us/usage/packages/overview/` - Technically we could even remove `slug`, as Hugo defaults to using filename, however at least with this PR it means `slug` only needs to be the name for the **current file** rather than an entire URL 2. This PR adds appropriate aliases (redirects) for pages, so anything on the internet that links to our docs should hopefully not break. 3. A minor nit I've had for a while, renaming `seek-help` to `support`. It's a minor thing, but `seek-help` has a strange connotation to it. 4. The commits are split such that you can review the first which is the "actual" change, and the second is added redirects so that the first doesn't break links elsewhere. --------- Signed-off-by: jolheiser <john.olheiser@gmail.com>
2 years ago
aliases:
- /en-us/guidelines-refactoring
Add some guidelines for refactoring (#22880) Just some brief ideas. Feel free to complete these guidelines, feel free to edit on this PR directly.
2 years ago
menu:
Nest metadata in refactoring docs (#23087) Whitespace was missing from refactoring docs metadata. backport label applied so it is included in versioned docs.
2 years ago
sidebar:
Restructure documentation. Now the documentation has installation, administration, usage, development, contributing the 5 main parts (#23629) - **Installation**: includes how to install Gitea and related other tools, also includes upgrade Gitea - **Administration**: includes how to configure Gitea, customize Gitea and manage Gitea instance out of Gitea admin UI - **Usage**: includes how to use Gitea's functionalities. A sub documentation is about packages, in future we could also include CI/CD and others. - **Development**: includes how to integrate with Gitea's API, how to develop new features within Gitea - **Contributing**: includes how to contribute code to Gitea repositories. After this is merged, I think we can have a sub-documentation of `Usage` part named `Actions` to describe how to use Gitea actions --------- Co-authored-by: John Olheiser <john.olheiser@gmail.com>
2 years ago
parent: "contributing"
Nest metadata in refactoring docs (#23087) Whitespace was missing from refactoring docs metadata. backport label applied so it is included in versioned docs.
2 years ago
name: "Guidelines for Refactoring"
Docusaurus-ify (#26051) This PR cleans up the docs in a way to make them simpler to ingest by our [docs repo](https://gitea.com/gitea/gitea-docusaurus). 1. It includes all of the sed invocations our ingestion did, removing the need to do it at build time. 2. It replaces the shortcode variable replacement method with `@variable@` style, simply for easier sed invocations when required. 3. It removes unused files and moves the docs up a level as cleanup. --------- Signed-off-by: jolheiser <john.olheiser@gmail.com>
1 year ago
sidebar_position: 40
Nest metadata in refactoring docs (#23087) Whitespace was missing from refactoring docs metadata. backport label applied so it is included in versioned docs.
2 years ago
identifier: "guidelines-refactoring"
Add some guidelines for refactoring (#22880) Just some brief ideas. Feel free to complete these guidelines, feel free to edit on this PR directly.
2 years ago
---
# Guidelines for Refactoring
## Background
Since the first line of code was written at Feb 12, 2014, Gitea has grown to be a large project.
As a result, the codebase has become larger and larger. The larger the codebase is, the more difficult it is to maintain.
A lot of outdated mechanisms exist, a lot of frameworks are mixed together, some legacy code might cause bugs and block new features.
To make the codebase more maintainable and make Gitea better, developers should keep in mind to use modern mechanisms to refactor the old code.
This document is a collection of guidelines for refactoring the codebase.
## Refactoring Suggestions
* Design more about the future, but not only resolve the current problem.
* Reduce ambiguity, reduce conflicts, improve maintainability.
* Describe the refactoring, for example:
* Why the refactoring is needed.
* How the legacy problems would be solved.
* What's the Pros/Cons of the refactoring.
* Only do necessary changes, keep the old logic as much as possible.
* Introduce some intermediate steps to make the refactoring easier to review, a complete refactoring plan could be done in several PRs.
* If there is any divergence, the TOC(Technical Oversight Committee) should be involved to help to make decisions.
* Add necessary tests to make sure the refactoring is correct.
* Non-bug refactoring is preferred to be done at the beginning of a milestone, it would be easier to find problems before the release.
## Reviewing & Merging Suggestions
* A refactoring PR shouldn't be kept open for a long time (usually 7 days), it should be reviewed as soon as possible.
* A refactoring PR should be merged as soon as possible, it should not be blocked by other PRs.
* If there is no objection from TOC, a refactoring PR could be merged after 7 days with one core member's approval (not the author).
* Tolerate some dirty/hacky intermediate steps if the final result is good.
* Tolerate some regression bugs if the refactoring is necessary, fix bugs as soon as possible.