aniani/gitea
1
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2024-11-04 08:17:24 -05:00
Code
2b749af505
gitea/docs/content/doc/contributing/guidelines-refactoring.en-us.md
Lunny Xiao e8433b7fe6
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>
2023-03-23 23:18:24 +08:00

2.3 KiB
Raw Blame History

date title slug weight toc draft menu
2023-02-14T00:00:00+00:00 Guidelines for Refactoring guidelines-refactoring 20 false false
sidebar
parent name weight identifier
contributing Guidelines for Refactoring 20 guidelines-refactoring

Guidelines for Refactoring

Table of Contents

{{< toc >}}

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.