Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don’t let code become stale.

  • silencioso@lemmy.world
    link
    fedilink
    arrow-up
    21
    arrow-down
    1
    ·
    1 year ago

    Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.

      • hglman@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Yes, that’s part of the point. Dumping all at once into a merge and asking people to comprehend it all isn’t particularly realistic.

    • agilob@programming.devOP
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      you are supposed to have written the tests and to have written your code with pair programming,

      I commented out the tests because they were failing, pipelines were green so I merged. Now it’s running on prod. What do you do?

    • MeanEYE@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      2
      ·
      1 year ago

      You lost me at “pair programming”. Having tests for what you can test is fine. But there’s code that simply can’t be tested, or at least not easily at which point you are just wasting time. Open source mantra is always great in my opinion… release early, release often. In addition to that have a test version of your software before you push it to production if there’s sensitive data. That’s usually good enough to catch issues.

      And he’s right, reviewing changes before merge just takes time and resources away from project while the master branch keeps moving. Merge, if there are issues, whoever submitted the change is obliged to fix it. You can always checkout earlier version.

      • dbilitated@aussie.zone
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there’s a conflict but the automerge keeps drift to a minimum so it’s less common and fixed sooner.

        better than merging poorly tested/reviewed code.

        and yeah, a small team of superstars doesn’t need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.

        it also leads to plenty of good conversations about the best way to implement, so overall it’s a win.

        • MeanEYE@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Well, Git was designed to branch out, not be a single repo with bunch of users. So one team can have a local repo, that in turn gets merged into big one, etc. Structure matters as you say. Small experienced teams move fast. Big teams require a lot of management and supervision. I still think it’s better to split people up into small teams and give individual tasks, or let them pick tasks that need to be done.