Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices can slow your application down

stackoverflow.blog

Post reply on HN
Print view View original

111–120 of 187 posts

Re: Best practices can slow your application down

#111

Post by rochacon »

arkh wrote: post #92

TDD does not mean "small unit tests at the method level in code". It means you code your test cases before you implement the functionalities. Those tests can (and IMO should) be behavior tests: then you can rip out all your code and replace it with whatever you like, even off-the-shelf software and your test suite will still run. The excuse of those kind of tests being slow or hard to setup mean only one thing: we ha…

I share the same opinion. Its been a long time since I read Kent Beck's book on TDD, but I don't recall him saying TDD = unit tests. When I see people using these as synonyms it feels to me they don't quite understood what TDD means and just jumped into this conclusion of "unit tests that check every method/line of code you write".

Testing behavior from the user perspective should be the goal, these are the kind of tests that bring most value in the long run.

Re: Best practices can slow your application down

#112

Post by im3w1l »

sgtnoodle wrote: post #68
ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

Adding test coverage might indeed destroy their performance, in that they might expose where their system's bottlenecks are and realize that they've been focusing on the wrong things. When it comes to performance optimizations, folks' intuitions are almost always wrong. It's important to actually test and measure stuff like that. I think it's true in general that modern CPUs are insanely fast at executing code within…

I think you need both. Intuition most of the time to prevent the problem of a little bit of slow everywhere adding up, and then profiling to make sure there is no huge thing hiding in the blindspot of your intuition.

Re: Best practices can slow your application down

#113

Post by jandrewrogers »

klodolph wrote: post #42
josephg wrote: post #32

Earlier quoted context omitted.

There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.

Not resource management. Resource efficiency. If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break it up into smaller microservices, the footprints are smaller and you have more options for how you schedule them. There is a tradeoff here—services that are too small have high overhead. Services that are too large are inefficiently scheduled. Services that are…

This assertion is making a lot of unwarranted assumptions about the software architecture of a monolith. You can have a monolith and total control over the resources at the scale of an entire machine. This can be extraordinarily resource efficient in a way microservices never are, and is often the default case when designing systems like databases or data infrastructure.

A monolith easily achieves 10x throughput of what microservices will do on the same hardware. Which is why people build monoliths, they can be extremely efficient. Microservices are usually about trading resource efficiency for organizational convenience.

Re: Best practices can slow your application down

#114

Post by Leherenn »

_0w8t wrote: post #24
tsimionescu wrote: post #12

Earlier quoted context omitted.

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…

I have seen a lot of projects that use interfaces in C++ or Java just to be able to mock the tests. This puzzled me. If it is known that the there will be exactly 2 implementations of the interface, one real one and one for mocking, then do not use interfaces. Instead use a global flag and at relevant places instead of calling interface’ methods just test the flag and branch for test/non-test code. If the flag is a c…

It massively hurts readability and can quickly become messy in my experience. If you're running on multiple targets and testing on host, then you have an #ifdef spaghetti in no time.

In all the codebases I have worked on, they started like this because it is easy, but then moved on to interfaces/templates because maintainability is an issue with this method.

Re: Best practices can slow your application down

#115

Post by andrewem »

vp8989 wrote: post #83
sgtnoodle wrote: post #68

Earlier quoted context omitted.

Adding test coverage might indeed destroy their performance, in that they might expose where their system's bottlenecks are and realize that they've been focusing on the wrong things. When it comes to performance optimizations, folks' intuitions are almost always wrong. It's important to actually test and measure stuff like that. I think it's true in general that modern CPUs are insanely fast at executing code within…

It's hilarious that you are skeptical of the competence of the SO core devs. You should do a little further reading, there is lots of content available online from the core devs who actually "do the work" there (ie, not the people who wrote this fluffy blog post).

FYI, the first listed author of this post has the job title Principal Software Developer, which I assume makes that person is one of the people who write the code.

Edit: added missing “is”

Re: Best practices can slow your application down

#117

Post by klingon78 »

stonemetal12 wrote: post #107
klingon78 wrote: post #87

Earlier quoted context omitted.

Something not mentioned but is a much bigger problem than performance for most is that if you write too many tests, you may be unable to easily upgrade/update to newer versions without a significant amount of work to update all of the tests. You’re right to call out performance as a reason for testing. Unfortunately, though, it’s usually not that easy. A problem not found in testing may be the result of inexperience…

Isn't that a bit of a red herring? Either I have automated tests that will take time to update every once in a while, or I have manual regression tests that I have to run for every code change. The automated test path seems to be the much less time intensive path, depending on how often you make big changes. On the other hand I really believe 100% unit test coverage is a bit of a waste of time. Unit tests should be r…

I meant upgrading application frameworks, OS, etc., so it’s not a red herring. Those can inflict a lot of changes if you have a lot of tests affected.

Re: Best practices can slow your application down

#119

Post by gambler »

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

>Why does the industry seem to love testing?

Because testing coverage is a typical way modern software engineers and managers show off an otherwise mediocre codebase.

>because we are better than all of you.

Well, at least they have something tangible to show for it. TDD elitism is much more ridiculous, because (as I've seen over and over) having high test coverage does not mean the code is bug-free or even properly modularized. If you want to brag about your tests, don't shot me your coverage, show me how you have 10 times less bug reports than the next guy.

Post reply on HN