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 reverse engineering is harder than coding on a blank slate.

  • Spider@lemmy.blahaj.zone
    0·
    2 days ago

    Responding as a java/kotlin maintainer of one single large system with frequent requirement changes. what i call “high entropy” programs. Other developers have different priorities and may answer differently based on what kind of system they work in, and their answers are also valid, but you do need to care about what kind of systems they work on when you decide whether or not to follow their advice.

    In my experience, if the builder of the original system didn’t care about maintainability, then it’s probably faster to rewrite it.

    Of course, then you’d have to be able to tell what maintainable code looks like, which is the tricky part, but includes things like,

    • Interfaces
    • Dependency injection
    • Avoidance of static or const functions
    • Avoidance of “indirect recursion” or what I call spaghetti jank that makes class internals really hard to understand.
    • Class names indicate design patterns being used. Such as “Facade”. This indicates that the original builder was doing some top-down software design in an effort to write maintainable code.
    • Data has one, and only one, source of truth. A lot of refactoring pain comes from trying to align multiple sources of truth, since disgreements cause mayhem to the program state.

    Bad signs:

    • Oops, all concrete classes.
    • Inheritance. You get one Base Class, and only one, before you should give the code the death glare. Its extremely difficult for a programmer to be able to tell a true “is a” relationship from a false one. For starters you have to have rock solid class definitions to start with. If the presence of Inheritance smells like the original builder was only using it to save time building the feature, burn it with fire! Its anti-maintainable.
    • Too much organizing - you have to open 20 files to find out what one algorithm does. That’s a sign that the original builder didn’t know the difference between organizing for organizing sake and keeping code together that changes together.
    • Too little organizing - the original builder shoved eveything into one God class so they could use a bunch of global variables. You’d probably have a hard time replacing a component so big. Also, it probably won’t let you replace parts of itself - this style forces you to burn down the whole thing to make a change.
    • Multiple sources of truth for data: classes that keep their own copies of data as member variables are a prime example of this kind of mistake.