1144
Now listen here you little shit (thelemmy.club)
submitted 5 months ago* (last edited 5 months ago) by to c/programmer_humor@programming.dev
105 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 5 months ago (8 children)

Many opensource projects are in same state, I know for sure my projects become spaghetti if I work more than a year on them.

Besides, I'd argue that if you need to rewrite (part of) it is because it wasn't maintainable in the first place.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 21 points 5 months ago (5 children)

    I disagree. Rewriting is a core component of maintaining a code base. It's the evolution of code. Not rewriting and hooking in some janky way is much worse. No one can see all the possible needs of code the first time they write it. Or even the tenth. Updating the code by rewriting sections is the healthier way to use everything you learned since the first time you wrote it to keep it clean and improve it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 5 months ago*

    Exactly. Elegant code requires domain expertise, which no one has on during the first attempt.

    Strident attempts at elegance during the first domain-expertise-free try tend to just result in different kinds of shitty code.

    Of course, experienced programmers can obviously achieve lower shittiness, from day one.

    But truly elegant code requires exploring the domain, and learning what works there.

    Shitty or barely-good-enough code often walks so that elegant code can someday replace it.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 5 months ago (3 children)

    Well, if rewriting is maintaining, everybody can write maintenable code.

    Did it become a mess? Rewrite time!

    For me the art is writing it so you don't need to rewrite and you don't need a janky temporary permanent workaround if requirements change. Clean interfaces, SOLID, plug-ins, etc. Can't do it myself, but the legendary 10x devs usually do.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 14 points 5 months ago

    The most maintainable code is built to be replaced with minimal impact.

    How much of the program will must be replaced if you remove one module? If you need to replace the entire program, then your program is not maintainable. Too much is heavily dependent on this module.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 5 months ago

    I don't believe in code that never needs a rewrite, but scalable code should be compartmentalized and future-proofed to the point that the next rewrite can be pushed as far into the future as possible. Me personally, I tend to discover what these best practices are during those rewrites.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 5 months ago

    All code is maintainable with enough time and money.

    But yes, well structured code where those rewrites are minimal is the goal.

    There probably is a threshold where the amount you have to rewrite becomes too high. But with each rewrite, hopefully the next time you have a section you need to redo its smaller that before. Eventually going from rewriting a couple thousands of lines to just a hundred or so on the 5th iteration.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 5 months ago (1 child)

    I disagree.

    Rewrites can happen due to new feature support.

    For examlle: It's entirely possible that a synchronous state machine worked for the previous needs of the software, but it grew to a point where now that state machine is unable to meet the new requirements and needs to be replaced with a modern fam with asynchronous singals/delegates.

    Just because that system was replaced doesn't mean that it wasn't maintainable, wasn't readable, or easy to understand. It just wasn't compatible with the growing needs of the application.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •