46
Software engineers hate code
(www.dancowell.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Jul 2023
46 points (96.0% liked)
Programming
17314 readers
68 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I think this post is too simplistic. Everyone handles good code, but as it works and doesn't cause problems nor raises eyebrows then we just glance over it and take it for granted. Developers spend a disproportional time glancing at bad code because that's where they work on, either fixing bugs or updating it to add features.
Microservices have zero to do with this. Their main features is imposing hard boundaries on independent components that are loosely coupled, and in the process end up with code that is safer and easier to change and even rewrite, simpler to deploy, and more testable. Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.
Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.
No one said that microservices architecture was a silver bullet. What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service. Being loosely coupled and having narrower and limited responsibilities naturally lead to simpler projects that are both more accommodating of changes and easier to replace.
Actually it does. Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code on microservices while their monolith is kept somehow clean, the narrower responsibilities alone result in simpler and more straight forward code implemented with a far smaller codebase. I'm not sure what leads you to assume that more responsibilities, features, and code paths can possibly make code easier to understand.
We only get this if we do microservices correctly. That's more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.
No, I don't believe that. However, I also don't believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it's monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it's more difficult to produce spaghetti (or easier to recover from it). I'm not sure that's the norm, though.
As a final note: I'm not saying microservices are bad, or monolith is better than microservices. I'm just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture: