• CrypticCoffee@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      6 months ago

      Yes, and you do it at the point you need to work on that feature. The business pay for it when they want the change.

      You do not pay for the refactor with your time, if the company won’t pay to fix their code. Just make it clear the risks and how bad it could be if you carry on with duct tape fixes.

      You have to be strong and firm and not agree to hacks. You need to work with your team to ensure you’re on the same page rather than getting undermined by cowboy dev claiming he can do the feature in 2 days when it needs 2 weeks to do the necessary work.

    • NocturnalMorning@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      Sure, refactoring is sometimes necessary. But refactoring also introduces new bugs often. Our code base is constantly being refactoring, and it’s not more reliable, stuff is constantly breaking.

        • NocturnalMorning@lemmy.world
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          6 months ago

          Why are programmers so arrogant? They do have unit tests, and a dedicated test team. Refactoring can and does introduce bugs. It’s a fact.

          • MyNameIsRichard@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            6 months ago

            Frankly, if your test suite isn’t catching 95% or more of the bugs, there’s a problem with the test suite and if uat aren’t catching 95% or more of the remainder, there’s a problem with uat

          • luciferofastora@lemmy.zip
            link
            fedilink
            arrow-up
            1
            ·
            6 months ago

            How solid is the unit test coverage? What about regression tests? If you get new bugs creeping in all the time, your bug-catchers aren’t doing their job