11–20 of 187 posts
> "Best practices, not required practices"
Is a thing mentioned from the article that I think many people forget. It also not only applies to programming or coding but rather to most things in life. Just because someone says it is best doesnt mean it is for you in your situation.
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?
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 are calling an interface which could be either the actual code or the mock code, the actual code can't be inlined, and that alone usually discards dozens of other optimizations. You can't specify in a language something like 'assume this implementation in optimized builds', so we're stuck.
There are ways around this, to be fair. In C#, you could ale all of your code generic, such that there could be two versions of your class - one with a real dependency, MyClass, and one with mocked dependencies, MyClass. Not sure if the C# compiler or JIT actually knows how to use this during optimization, but in principle it could. With C++ templates this would definitely allow optimization. With Java's extremely advanced JIT, you wouldn't actually need this code change, the compiler will be able to do it for you after a few thousand runs through the code, when it notices a single version is being called.
In my opinion, the idea that you can have well-tested code OR performance is tosh. If you don’t have good testing and do it regularly how can you refactor your application for speed if you’re not going to be sure that you’re going to introduce a regression? And I think the stackoverflow team know it: > Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. I…
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…
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 microservices.
I agree it is easy to fall into the trap of thinking that tests are boring though as devs become more experienced there should be less of that thinking, hopefully.
In my opinion, the idea that you can have well-tested code OR performance is tosh. If you don’t have good testing and do it regularly how can you refactor your application for speed if you’re not going to be sure that you’re going to introduce a regression? And I think the stackoverflow team know it: > Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. I…
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…
I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising.
I really don’t think it’s a model to follow.
In my opinion, the idea that you can have well-tested code OR performance is tosh. If you don’t have good testing and do it regularly how can you refactor your application for speed if you’re not going to be sure that you’re going to introduce a regression? And I think the stackoverflow team know it: > Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. I…
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…
I always end up writing tests for my programs, but with all the stubs and fixtures and weird stuff I get into hairy problems that I don't understand. Tests are supposed to be helpful, but writing good tests is ridiculously hard.
Or maybe it's just because I'm a perfectionist, and I should be happy with crappy tests that at least give me a little bit of information about regressions
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…
It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it. I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising. I really don’t think it’s a mode…
Until customers start caring a lot about development slowing down orders of magnitude down the line and hold their providers accountable, development will continue cutting corners where possible. Unfortunately, testability in particular is one aspect which doesn't have amazing support in regards to how much value it adds.
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…
It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it. I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising. I really don’t think it’s a mode…
It's not a model to follow because it was a way of working that fit their requirements at that point in time. Given a different company, project, team, ecosystem, etc, the decision may well be different.
Thus, you shouldn't follow their model unless you are identical in every way.
What you should follow is the way they arrived at a decision, not the decision itself.
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?
Earlier quoted context omitted.
It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it. I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising. I really don’t think it’s a mode…
It is when time to market with a feature-complete product is your primary concern, and testability isn't shown to be helping that metric for the developer's specific case. Until customers start caring a lot about development slowing down orders of magnitude down the line and hold their providers accountable, development will continue cutting corners where possible. Unfortunately, testability in particular is one aspe…
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 distributed Microservices applications.