Writing a, for me, quite big system and had about everything ready to go, the earliest version about works.

But, it's written for one (broad) specific use case and guess what: in the past few weeks, a few other use cases have presented themselves. The 'principle' is the same so I could integrate them into the current system, but; then I'd have to rewrite the entire thing to be more flexible.

I think I'm going to do that but damn I've been debating this for hours now 😬

  • 5
    Had the same case short ago and ultimately the first version got so messed up that I couldn't extend it enough anymore to cover all cases. It's quite often that, while thinking about the code, you easly find many parts that you would write better now and then it's probably worth it.
  • 8
    Fuck it, I'm rewriting it.
  • 2
    effortIn() < valueOut() ? this.rewriteProject() : this.nahFuckIt()
  • 2
    That's why you should follow modular design practices and not create monolith spaghetti code (not saying you did but happens at my work when I'm not the one writing the code).

    I did a semi rewrite of old code last 2weeks but was pretty much able to reuse a lot of old classes with some refactoring and then just building a new "frontend"
  • 3
    @billgates I write everything OO and in this case I just noticed that I only have to rewrite parts, I can divide everything into classes/objects easily!
  • 0
    I forgot how much thinking went into this last time 😅
  • 1
    @billgates it's really hard to know what you have to abstract in your architecture and not overdevelop with just one use case. I have a tendency to make everything flexible but only when a few use cases pop up i get it right.
    Ideally you have a framework ready and just have to write a few strategies or adapters. A few of my projects got to that point (highly reusable) but sometimes a quick and dirty script is the more maintainable solution
  • 1
    @hjk101 well general guideline is just don't make spaghetti code: god classes/functions, super nested ifs... (JS functions that pass callback which has more ifs that pass another callback, ...)
  • 2
    @billgates you are still mixing bad practices with unsuitable architecture.
    Not once did I or @linuxxx say we write low quality unreadable crap.
    The problem here is that it is not suitable for 3 similar usecases without duplicating a lot of code (injecting a slew of classes for each case) or if-ing the crap out of it.
    As a general rule I write code with lose coupling, strong cohesion and mostly pick DI over inheritance.
  • 2
    @hjk101 This.

    I am able to extend the application to a certain 'modular' point but the cases which just came up simply aren't as modular as I wish.

    Still, I've been able to make it quite modular. And everything is based on classes/objects
Your Job Suck?
Get a Better Job
Add Comment