31–40 of 187 posts
In many applications things like having a testable, easy-to-read, well-structured codebase can trump performance, and it's often worth sacrificing a bit of performance if it means it's easier to refactor and build new features.
Earlier quoted context omitted.
I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large systems to be built by parallel teams while maintaining productivity and quality both technically and organisationally. That said, I’m a strong proponent of monolithic architectures until scale becomes a problem.
It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.
I've consistently heard good things about Erlang/OTP.
Performance is a feature, and so is being able to reason through a codebase.
Being able to fit all the pieces in your head is a feature, but not so snappy.
This should be obvious. Writing well-structured, decoupled, modular code can make you lose track of performance concerns. And since no one likes to write things more than once, so there's only "one shot" at writing the application, people tend to err on the side of "well-structured", because hey, who's gonna fore you for following best practices?
Writing "well-structured, decoupled, modular code" is a best design practice for a good reason. It what leads to best results overall, where "best results" means code that is easier overall to test, maintain, modify/expand, and optimise as needed.
Regarding optimisation, something related to keep in mind is that optimisation at system level (which is often the desired end result) is not the sum of independent local optimisations.
Earlier quoted context omitted.
Very, very few people know how to make cheap tests. I have one guy who writes fixtures that couples all of his tests. When I need to add functionality, first I have to replace his fixtures with basic stubs, just so I can add another bit of functionality. And we have two people who copy his coding style. Probably to fit in. I think, based on my own experiences and working with people learning to write tests, that 'sim…
Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microse…
No, more than that, it's a sign that the tests are not just testing for how code behaves, but also its implementation details.
With well-written tests, you can completely re-structure some code and, if it still does the same thing, the tests for that code will still pass.
If the code being changed has several components with their own tests, then either those components have no interface change, in which case the previous paragraph applies to them, or the do, in which case their tests should be easy to adapt.
Earlier quoted context omitted.
You're missing the development time dimension. The point of the SO post is that, given a limited development time, they chose to focus on performance and sacrifice testability. Many years later now, they are choosing the opposite. This doesn't make their initial decision wrong. The site exists and has thrived, and has achieved all of its performance goals. So the decision was correct. If it has now become too hard to…
> The point of the SO post is that, given a limited development time, they chose to focus on performance and sacrifice testability. I used to think that this was necessarily a choice for a long time, in fact I only very recently started writing almost TDD (not completely, there's things that I will still write code first, but no longer do I leave it untested, and I also don't see a problem in writing contained parts…
The upshot of this is that you will get disproportionate value from the first few tests you add to a project. I think its very rare to have a long lived project in which the first 10 tests aren't worth writing. The next 100 tests? That's a much harder question.
Earlier quoted context omitted.
I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large systems to be built by parallel teams while maintaining productivity and quality both technically and organisationally. That said, I’m a strong proponent of monolithic architectures until scale becomes a problem.
It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.
Similarly, you could do TDD on a high percentage of the code by using injection, then automatically rewrite the code into static methods, as Atwood was saying they needed for performance, if that’s what would help.
Code generation, etc. got a bad name over the years as people tended to use it to balloon the eventual source, like that of many autogenerated config files today, but it can be used to do almost anything.
Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…
I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large systems to be built by parallel teams while maintaining productivity and quality both technically and organisationally. That said, I’m a strong proponent of monolithic architectures until scale becomes a problem.
You don't end up with lots of network calls for one use case and still have good maintainability.
I have to admit I would far rather work on a conceptually simple codebase, that has been kept fast and light with minimal testing, than to work on a conceptually muddled codebase with 100% testing. Performance is a feature, and so is being able to reason through a codebase. Being able to fit all the pieces in your head is a feature, but not so snappy.
How about "architectural sanity is a feature"?
It kind of isn't though. Clients don't care about qualities of your code that they can observe. They notice if your code is fast, but don't care it it's easy or hard to reason about.
If anything, I'd say it's a bit of a meta-feature, because code-quality is directly linked to many other properties that people do care about (speed, new features, quick bugfixes, etc.)
The argument against Tests sounds like a tooling problem to me. Why shouldn't a compiler be able to optimize the modular approach to the same code that a monolithic approach yields?
Why is that relevant? The fact is that it doesn't (there are good reasons for it, but that is another matter). You can't work with the ideal tools, you can only work with the tools that actually exist. So, with the actual tools, this sacrifice must be made. And now do answer your actual question, the reason is that the languages we use are just not expressive enough, and the compiler doesn't have enough time. If you…
In any case, for the vast majority if code bases, maintainability is more important than 10% better performance.