Refactoring gets really bad reviews, but from where I’m sitting as a hobby programmer in relative ignorance it seems like it should be easier, because you could potentially reuse a lot of code. Can someone break it down for me?

I’m thinking of a situation where the code is ugly but still legible here. I completely understand that actual reverse engineering is harder than coding on a blank slate.

  • Nighed@feddit.uk
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    6 months ago

    I’m almost always of the opinion that refactoring is better than a rewrite as long as the tech stack is supportable.

    Everyone wants to rewrite stuff, because the old system is ‘needlessly complicated’. 90% of the time though, they end up finding it was complicated for a reason and it all ends up going back in. It does allow a system to be written with the full knowledge of its scope though, instead of an old system that has been repeatedly bodjed and expanded. Finally, if your old tech stack is unsupportable (not just uncool, unsupportable) then it can be the most feasible way. It will take ages though with no/little return until it’s all finished.

    Refactoring is more difficult, as developers need to understand the existing codebase more to be able to safely upgrade it in situ. It does mean you can get continuous improvement through the process though as you update things bit by bit. You do need to test that each change doesn’t have unexpected impact though, and this can be difficult to do in badly written systems.

    Most Devs hate working on other people’s code though, so prefer rewrites.

    (Ran out of time to go into more detail)

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      How would you define “supportable”?

      Most Devs hate working on other people’s code though, so prefer rewrites.

      I now suspect this is basically where it’s coming from.

  • corsicanguppy@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    6 months ago

    Refactoring is good work. Rewriting is shallow fun.

    Do the math.

    Exception: perl is write-only code. Always rewrite.

  • frezik@midwest.social
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    Rebuild from scratch gets a bad reputation sometimes because it’s the go-to response of a junior programmer with a little experience. They know the system could be done better, and it seems like the fastest way to get there is to throw out everything.

    What often happens next is the realization that the existing system was handling far more edge cases than it initially appears. You often discover these edge cases when the new system is deployed and someone complains about their use case breaking. As you fix each one, the new system starts to look worse than the old while supporting half its features.

    This often leads people to prefer refactors rather than rewrites. Those can take a lot longer than expected and never quite shed what made the old system bad. Budget cuts can leave the whole project in a halfway state that’s worse than if it was left alone.

    There are no easy answers, and the industry has not solved this problem.

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      What often happens next is the realization that the existing system was handling far more edge cases than it initially appears. You often discover these edge cases when the new system is deployed and someone complains about their use case breaking.

      The reverse is also sometimes true and it’s when a rewrite is justifyable.

      I’ve worked with many systems that piled up a ton of edge cases handling for things that are no longer possible, it makes the code way harder to follow than it should.

      I’ve had successful rewrites that used 10x+ less the amount of code, for more features and significantly more reliable. And completely eliminated many of the edge cases by design.