Spike: Investigate linting rules to catch performance & memory anti-patterns

https://gitlab.com/gitlab-org/gitlab/-/jobs/424903546

Problem to solve

To make GitLab perform well and consume less memory in the long term, we need to focus more on preventative measures than just after-the-fact fixes and optimizations. By introducing linting rules that run as part of CI, we could nudge developers toward rethinking their implementations if they use language constructs that are known to cause performance issues at scale.

Intended users

Developers

Proposal

The goals of this spike are to:

• Review any existing performance checks we perform as part of CI and see how they could be expanded upon
• We use RuboCop for linting, and the majority of our code is written in Ruby; investigate if there are existing linting rules that could or should be enabled to catch potential performance issues.
• If existing rule sets are have gaps, investigate how custom rules could fill these
• Lay out a plan for how this could be integrated into CI; we need to strike a balance here between catching important issues early, but at the same time not becoming an impediment to developers, as that will most likely result in them simply ignoring the reports

Break out actionable issues where relevant.

What does success look like, and how can we measure that?

Have a better understanding of:

• what CI linting rules are suitable to us
• how will they be used or created
• how will they be integrated into the existing development workflow

Answers need to be specific enough for follow-up issues to be "ready for development".