HELP! My system is hard to change
ฝัง
- เผยแพร่เมื่อ 13 ก.ย. 2024
- If you're frustrated working in a large spaghetti code system that's hard to change and easy to introduce bugs, you've probably wanted to rewrite everything from scratch. The reality is that's not likely going to happen. However, here's how you can think about untangling the spaghetti code mess in smaller chunks one at a time, making it more manageable.
🔗 EventStoreDB
eventsto.re/co...
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via TH-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c...
#softwarearchitecture #softwaredesign
I glitched out at 6:34... good thing I didn't swear! 🤣
FRICK
I know what you were gonna say 😉
This is a good presentation. And I'd argue that you aren't fixing a spaghetti code problem, but a systems-level coupling problem. From the title I thought you were going to tell us how to unravel an unwieldy bit of coding. Still, I think this is an excellent explanation of the value of decoupling. Nicely done, and continued success!
Agreed. I've updated the title and thumbnail.
I even replayed that moment, it's just more human this way :)
"Spaghetti Code" was so-named in the pre-structured code era. Back then we only had "GOTO" statements for branching and you could jump into the middle of a subroutine and return out of it. ForTran and COBOL as well as BASIC were notorious for it. Especially if you had a low memory machine (like many 70s microcomputers) you'd find code that branched wantonly from one routine to the next, borrowing instructions from here and there to save space. If you tried to draw a flowchart of this code, it looked like a ball of spaghetti. And now you know... the rest of the story.
Quite often people say we can't rewrite sphagetti code from scratch because it is "unrealistic" -- that is a symptom of sunk cost fallacy -- in a number of cases. One factor people have not considered is opportunity cost. The amount of resources you spend refactoring -- keep this here and make small changes -- might be so high that a complete rewrite might work out to be cheaper.
Great video, it feels so relatable! In the system we're maintaining we recently discovered that another team was actually reaching directly into the DB, completely bypassing the api and any validation. I also remember once when we were cleaning up in the logs, then another team reached out and asked us to stop - it turns out they were using regular expressions to parse stack traces, and using them for their "bussiness logic" :D. So I think it is not only a question of having a good structure of your code, logical boundaries or infrastructure, all effort must begin in the minds of the developers. If the developers think it OK to take the "shorter path" then all efforts will be eventually undermined.
Good fences make good neighbors
I had same experiences.
Argh, that also means fetching CDC by log-mining from our Enterprise Oracle DB isn't the right solution, but unfortunately, if we must get CDC, but have no way of refactoring the legacy monolith to publish events to our Kafka, we have to live with this coupling.
Legacy code is difficult to extract due to so many devs managing to hobble it together like a Winchester House
THEY HAD TO SHIP IT TODAY OR ELSE THEY GET FIRED
and often times they just left and didn’t leave any notes
This seems to be industry standard bc every job I’ve been on has been like this
Ya, it's pretty unfortunate thats the case too often. Often taking the path of least resistance or piggy backing off another feature when they are totally different concepts.
@@CodeOpinion what are some techniques to talk to management about why they are in this situation and it's likely not to get any better without a lot of work?
They all balk and say "yes you are right but could you just fix this one thing?"
And the "one thing" has been patched over more times than the greens in caddyshack after Carl Spackler got rid of the gopher problem
And there seems to be some leftover "gopher eradication" devices blowing up stuff everytime I touch the code
@@ChrisAthanas honestly it takes a major cultural shift to break the tech debt crack habit. You can't fix it at once, so you leave everything you touch a bit cleaner than how you found it. Over time things get better. I don't think there are any shortcuts to fixing spaghetti code but are spending that time anyway fixing the bugs.
@@HarveyKane I'm starting to understand that projects need to be rewritten sometimes. Business think the code is an asset but over time it always becomes a liability and business has not adjusted to this fact yet
Every line is a liability needs to be a new rule
@@ChrisAthanas I find that spaghetti code is usually an organizational problem: if there's no clear ownership of the code (as in, this belongs to team X, only they are allowed to touch it), it tends to degenerate quickly. That's where management can help.
I’d buy a t-shirt that says “Manage coupling between logical boundaries. And logical boundaries are the cohesion.”
Let's say you have several thousand stored procedures with thousands of lines each, each with tightly coupled business logic, and a facade an api layer that ultimately always calls one of said stored procs. What would you recommend? Every api ultimately can call any db table or proc and its the biggest mess of ive ever seen.
Best to rewrite the whole damn thing would be my guess. So, start by rewriting the supporting services and create their own stateful stores separately and make the main monolith only interact with the supporting service via API calls. Same way carve out gradually other services and rewrite them. Easier said than done ofcourse.
And it is a place where CQRD comes up. Each command handler creates small api which handles a whole one business operation.
Yes, CQRS and vertical slices can help you here as it helps you focus on the business operation rather than focusing purely on data/entities.
Great video, Derek. This provides a potential path out of the wilderness for many. I emphasize potential because it also provides some guidance to make an honest assessment of the feasibility and practicality of doing so.
In many cases, the gap between an existing architecture and one which has a viable and maintainable future is simply too large to close and the organisation must make the difficult choice to leverage the domain knowledge rather than the implementation and start over on a better foundation. Many of the largest platforms we know have gone through this phase, often more than once. Let's not kid ourselves, however, it's a huge investment that few are able to take on unless they are already on a growth and investment trajectory.
Organisations that lack the budget, skills and foundational domain knowledge to make this transition are, unfortunately, in a really tough spot. In reality, they've been living on borrowed time with an undiagnosed terminal architecture condition. To survive, they will have to make significant changes to their platform, many of which will impact their clients. Their future will likely depend on how invested and willing their clients are in participating in this journey together.
what you said make great sense.
Hi Derek! Thanks for the video! How would you handle a situation, when one logical boundry needs some data from the other one, but the amount of data is so big that using API is not an option, I had to include it to the DB query. It feels wrong but I don't know how to get rid of it, yet the boundries seem to be set correctly.
This can often happen because of reporting. Depending on the use of the data, you can dump it to somewhere meaningful that another boundary can import/use. I'm often very carful with this that this data isn't used for invariants where it needs consistency. But this happens a lot when composing data for reporting/bi purposes.
@@CodeOpinion thanks for the answer!
I have always said lasagna is more delicious than spaghetti. Now you know!
Hey Derek, what do you think about "Even Storming" to help define boundaries by grouping related events together ?
It’s a good idea and requires an event driven architecture, which vast majority of these legacy projects are not built that way, so event storming is likely not going to help in this situation
@@ChrisAthanas No it does not. Event storming precedes any implementation, it's a business/domain analysis not a technical one. I think it can help you categorize and structure behaviors, even if u don't use real "event" implementations.
No it's really useful to see the workflow between boundaries and how one often hands off to another. Internal workflows that define a larger business process.
@@CodeOpinion this usually requires a lot of analysis, and legacy code is usually being worked on bc it's broken and no one left around who knows how to fix it and they are losing money
They want it fixed
Not analysis
Please help me on how to handle this situation
Derek why would you attack me like this
Coop... Coop-a-loop.
But but but..... I love spaghetti 😢
The food but not the code
What a nightmare