Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
It's basically like dissecting a cancerous tumor.
With an additional risk factor: Time.
When you rewrite something from scratch, the moment you finished a task, the code written might already be "out of date" (libraries, dependencies, ...)
It is a very risky move - you should have the resources for maintenance, ongoing development / migration, regression fixing. You will need to do a lot of task juggling, reevaluation and adaption - as most likely you'll find a lot of "surprises".
You should be honest to the team about that - don't try to "beautify" failures / set backs. Perseverance is key.
That said, micro frameworks are great in theory. In practice, it requires dedication and strictness - if someone tries to take the easy road, they need to be stopped.
Deviation from a micro framework *will* be a huge problem - most likely you're already stretched thin, but supporting then different dependency chains / upgrades / migrations will be really a coffin nail.
So far, so bad :)
Takeaway is: Prepare, adapt, be rigid and persevere. Make clear rules and workflows for dependency handling and migrations steps, documentation is important.
Is it worth it? If you do it right, yes: You end up most likely with a consistent, unified dependency chain (ease of further development, security, less required / easier knowledge transfer) and a cleaner architecture.
Plus you might be able to modularize the system - as you already have to untangle a lot of "inter" architecture dependencies (e.g. module a requires module b requires module c), which gives you the chance to properly isolate modules.
These are all things which benefit in long term.
Very well put! Thanks.
I’m honestly thinking about rewriting the entire client side and only using micro frontends for features that need to be developed asap, so they can be reintegrated into a new client with an ease.
The platform is not that complex. It should take 3 months at most for any experience (not even a senior) engineer to write it correctly and document it. It baffles me that previous guy took 2 years to do it.
I’ve asked a guy why he did and use X instead Y.
> because it was interesting
That’s the state of entire tech. side of the product - done X because seems interesting.
Can’t fire the guy (yet) as he is the only one who can produce features quickly and make other C level executives happy.
At this point, it seems that my entire career is about making cakes out of 💩. I’m getting better at it every year.
Allright Mr manager.
That would be USD XX,XXX.
Thanks to @IntrusionCM, it was free!
yehaaw269592d@scor I didn’t get it
@yehaaw oh yeah.
It's new, it's shiny, it's interesting.
Let's cram it somewhere in even if it doesn't fit.
Or the exact opposite: We have always done it like that... So we must do it like that.
When people ask me why I have trust issues and need anger management, I usually just point that out and the lil hint that this happens at least once per month... Its really one of the things that can chip down any emotional defense just because it's so completely annoying and waste of time.
nebula187986ddepending on your exact case it might also be valid to spawn a new client and route between them.
if client 2 has feature A done, go to client 1 and route that thing to the new client.
migration is done over time while keeping the system running.
client 1 will die if everything got migrated.
Alright, I need an advice.
I have legacy Angular client. It’s impossible to refactor it. The only real option is to rewrite everything from scratch, however, while the team does it, it needs to be accessible to our clients.
The approach I am thinking of is making micro-frontends out of original client and rewriting each of them (in React, Vue, don’t know yet.)
Anyone has experience with that? I would appreciate any advice or suggestion.