Best practices can slow your application down
stackoverflow.blog
Best practices can slow your application down
1–10 of 187 posts
Re: Best practices can slow your application down
#2This 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?
Re: Best practices can slow your application down
#3Duplicate of [https://news.ycombinator.com/item?id=26381640}]
Re: Best practices can slow your application down
#4In 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. It’s an engineering goal we aim to achieve, but the changes needed are significant.
This makes it sound like a lofty goal but I think it just sounds more like. “Oh crap, we’re sitting on a mountain of tech debt”
No I know you can’t always expect to arrive at a project and find the sunny uplands of TDD and continuous delivery but if you do get to “optimised for speed” code (to me that’s a synonym for tech debt that’s slowing down delivery) all you can do is slowly add what should have been done in the first place (tests).
Re: Best practices can slow your application down
#5The 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?
Re: Best practices can slow your application down
#6In 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 'simple' tests often feel more like the pejorative meaning of the word. They get uncomfortable, like you're debasing yourself to write such boring code. Surely I can write more interesting tests.
Yes, you can write more interesting tests if your goal is for nobody to ever touch your code. Mine, mine, mine. The best tests, I know where my new code went wrong simply by reading the test output (not the test). If I refactor I should be able to maintain that coverage even if the order or structure of things gets completely switched around.
Complex tests begat complex tests. If your old test is 2-3 lines of code, I just delete it and write a new one that does the same thing.
Re: Best practices can slow your application down
#7The 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?
As long as dynamically loading code at runtime is allowed, proving that there will only ever be one implementation of an interface isn't going to be possible. That makes fully optimizing away the cost of the indirection difficult.
Re: Best practices can slow your application down
#8In 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…
> This makes it sound like a lofty goal…
Sales pitch 101. Sell your weaknesses as strengths.
Re: Best practices can slow your application down
#9In 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 maintain, perhaps the decision to sacrifice some performance to achieve testability will be correct as well (since it seems they haven't finished yet, we can't judge the results).
Re: Best practices can slow your application down
#10This 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?
[deleted]