upvote

points

by bottlepalm15 hours ago |
comments
upvoteby jcgrillo14 hours ago|
[-]
It happens in poorly factored codebases. If you find it happening that's a sign you need to refactor. If you find it happening repeatedly in the same codebase that means you failed to refactor properly the first time.
reply
upvoteby democracy12 hours ago|
parent|
next
[-]
Not many industries can afford refactoring of the code is not supposed to be changed - additional (unexpected) regression testing costs, risk of downtime, etc. You learn that if it works and is in production - don't touch it.
reply
upvoteby bottlepalm13 hours ago|
parent|
prev|
[-]
Refactoring is the natural evolution of a growing application. Refactoring too soon, too fast is what we call over engineering. Too little refactoring and your code becomes spaghetti slop. Regardless - the application will change across all layers across its lifetime.
reply
upvoteby habinero12 hours ago|
parent|
next
[-]
Overengineering is totally a thing, yes. If you want to make a proof of concept or you have no customers, that's fine, ship it.

There's such a thing as under engineering, and if you find yourself changing "all the layers" for a feature, your codebase is poorly designed.

reply
upvoteby skydhash12 hours ago|
parent|
prev|
[-]
How many layers does your code have?

Even with clean architecture, you only have 4 fundamental layers. And once you have v1, you’re mostly doing tweaking and copy pasting. Any huge refactoring is the business switching its main strategy.

Take an OS like OpenBSD. It has three main layers. The syscall layer, the kernel layer, and the machine dependent code. But an OS is more spread horizontally with various subsystems (process and memory, io and other device, ipc,…)

If you’ve captured your problem’s domain and adopted a pragmatic architecture, you will rarely have to change across all layers. That’s costly and happens mostly due to business reasons.

reply
upvoteby bottlepalm2 hours ago|
parent|
[-]
Lets see, front end presentation, front end service, frontend api, backend to front end (BFF) api/routing, BFF logic, BFF api, backend routing, backend logic, backend database, worker routing, worker logic, worker storage.

And then the each of the service layers can be broken into layers themselves depending on the complexity of the business logic can be broken into layers as well. So yea a change in a worker can potentially bubble up through all the layers.

reply
upvoteby habinero1 hours ago|
parent|
[-]
In a worker? ...How? I seriously want to know.
reply