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.

  • magic_lobster_party@fedia.io
    link
    fedilink
    arrow-up
    2
    ·
    2 days ago

    From a professional perspective I’d say: don’t rewrite if you’re unsure about it. Rewrite if there’s a particular problem you need to solve and a rewrite is the only way to do it.

    For example, you need to make major changes in the tech stack. Like switching from PHP to NodeJS. This is difficult to do without a complete rewrite.

    Rewrite for the sake of rewrite is usually a waste of time, and it’s not certain that the code will turn out better in the end. You might end up with a similarly convoluted system either way. And the worst part is: now you have two systems to maintain at the same time.

    Likewise, refactor if there’s a particular problem you want to solve. Don’t refactor just for the sake of refactoring. If you don’t have a clear goal, then you’re just scrambling the code around.

    From a hobbyist perspective: do whatever you feel like. A complete rewrite can be a good learning experience.

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      1
      ·
      15 hours ago

      Yes, do nothing is an option too, of course. When this has come up on Lemmy, it’s usually because there’s an identifiable issue.

      Personally, I’m not really in the market to refactor anything right now, this isn’t a practical question. Honestly there’s plenty of FOSS that hasn’t been made the first time.