Skip to content

GitLab Next

    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Menu
    Projects Groups Snippets
  • Get a free trial
  • Sign up
  • Login
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar

GitLab 15.0 is launching on May 22! This version brings many exciting improvements, but also removes deprecated features and introduces breaking changes that may impact your workflow. To see what is being deprecated and removed, please visit Breaking changes in 15.0 and Deprecations.

  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #13484
Project 'gitlab-org/gitlab-ce' was moved to 'gitlab-org/gitlab-foss'. Please update any links and bookmarks that may still have the old path.
Closed (moved)
(moved)
Open
Created Feb 16, 2016 by Grzegorz Bizon@grzesiek💡Maintainer

Use decorators and interface segregation to solve overgrowing models problem

Summary:

Using decorators to segregate interfaces and improve testability may be a good solution for overgrowing models - https://gitlab.com/gitlab-org/gitlab-ce/issues/13484#note_3972945

Original issue:

According to this discussion, we can try moving build implementation to separate concerns, which can have some benefits.

Example: https://gitlab.com/gitlab-org/gitlab-ce/blob/6536a51c9034e1260bf4139b41d4c69c3cf2cf00/app/models/ci/build/erasable.rb

Reasoning behind this:

  1. We have less implementation in a single file - it is easier to browse it
  1. We have semantically coherent implementation in separate files - it is easier to find elements related to each other, for a given feature (like implementation that supports build erase only)
  2. We can exercise concerns inside separate tests - it is easier to maintain main model spec suites
  3. We can easily remove a feature if we decide so
  4. In some case we prevent merge conflicts between CE -> EE, as EE only features can go to concerns and it is only one common line between CE and EE in a model, also specs become separate files
  5. If we decide that this implementation belongs somewhere else it is then easier to move it to different place
  6. We improve maintainability of our models
  7. We make contribution barrier lower, model with 1000+ is difficult to understand, and as long as we keep our concerns separated and coherent, it is easier to understand what is going on (however I think that using composition instead of mixins/inheritance would be better here, see commit comments above, mixins are more idiomatic)
  8. We are able to introduce a starting point for structure/architecture.

@ayufan, @DouweM, @rspeicher what do you think about it?

Assignee
Assign to
Time tracking