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

181–187 of 187 posts

Re: Best practices can slow your application down

#181

Post by hinkley »

azeirah wrote: post #15
hinkley wrote: post #6

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…

I never got to understand testing. It's a thing that every developer is supposed to know and do well somehow. 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…

Pain is information, and an encouragement to change what you’re doing or how you’re doing it.

A little reorganization of your code can make an order of magnitude difference in how fiddly the scaffolding is. Does that mean your code structure is informed by tests? Yes, yes it does. But classic car designs are informed by access for repairs, and some vehicles are cherished for their ease, others become a topic of complaint and camaraderie. Really any industrial design has an element of this.

Re: Best practices can slow your application down

#182

Post by hinkley »

wccrawford wrote: post #74
azeirah wrote: post #15

Earlier quoted context omitted.

I never got to understand testing. It's a thing that every developer is supposed to know and do well somehow. 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…

It's one of those things where people who really believe in it are very vocal and will shout over anyone who dares to think there are any problems. Not everyone loves them. But, as I'm a test-lover, I have to say they're pretty amazing if you can get everyone on-board and writing good tests. As for how hard they are... It depends on how the code is structured. If the code is designed to be testable, it's pretty easy…

> I have to say they're pretty amazing if you can get everyone on-board and writing good tests

This is my main complaint about code coverage metrics. I want you to be good at test writing before you write the bulk of your tests, not after. It’s hard enough to get people to write good ones, let alone go back and fix the messy ones they wrote badly (recall I said good tests are easier to replace than bad ones).

If you write a bad enough test it can take longer to fix it than throw it out and start over. But since you didn’t clearly capture the constraints the first time, do you dare delete it? What aren’t you testing after?

Re: Best practices can slow your application down

#183

Post by kthejoker2 »

helsinkiandrew wrote: post #101
Cthulhu_ wrote: post #89

Earlier quoted context omitted.

They're really not selling their codebase or practices to me to be honest. If their system is built like that it might have enough performance to run a top x site on only a handful of bare metal servers, but the article also implies there's a lot of "here be dragons" code - don't touch this, you are not clever enough to test this, and since we don't have tests, you might break it by touching it. Which is just bad pra…

> the article also implies there's a lot of "here be dragons" code Agreed, fine if enough of the core developers are around, but if the company merged, the app needed to be extended or altered significantly, or some of the underlying technology stack is deprecated/becomes unsupported keeping things working will be very expensive.

Reminds me of "tech debt as a lack of understanding"

https://daverupert.com/2020/11/technical-debt-as-a-lack-of-u...

> If there’s been enough organizational turnover or enough feature creep in a product, then maybe doing a rewrite is the best option so your team has a collective understanding of the code. You can’t expect people to be productive in something that was a culmination of [complicated "here be dragons" code] made by people who no longer work there. At that point your technical debt balloon has popped, you are in possession of a toxic asset.

Re: Best practices can slow your application down

#184

Post by tsimionescu »

beny23 wrote: post #155
BlargMcLarg wrote: post #27

Earlier quoted context omitted.

Emphasis on " I think ". Unfortunately, your thinking hasn't had a whole lot of support, as studies have found both findings in favor of and arguments against TDD, both short term and long term. Furthermore, I would ask you to name the contexts in which you believe TDD to be better in the short term. Things differ when a lot of critical and non-trivial data-modifying code exists compared to an interface which changes…

Ok, my bad for “I think” - I should have said: in my 30 year experience I’ve yet had to come across a system were good tests were a hindrance to performance. I’ve had many a time where complex investigations into performance problems were uncovered by systematic and automated tests. If performance is a main goal, then surely TDD with performance in mind will give you a better advantage

Your comment was interpreted by many as "you can develop faster with testing than without" which is quite controversial. If you meant "quicker" as in "faster code", then that seems more plausible.

Re: Best practices can slow your application down

#185

Post by tsimionescu »

hnedeotes wrote: post #30
tsimionescu wrote: post #9

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…

> What I've found it really helps is when you have to tear down a prior specified behaviour/request/spec, or update it, or integrate it with other things.

Honestly, in my experience, the opposite is true of unit tests. I've never been able to make a significant change to a piece of code that was thoroughly unit tested without having to more or less re-write the unit tests from scratch.

However, integration tests and whole-project automation do help tremendously in what you are describing.

Re: Best practices can slow your application down

#186

Post by hnedeotes »

tsimionescu wrote: post #185
hnedeotes wrote: post #30

Earlier quoted context omitted.

> 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…

> What I've found it really helps is when you have to tear down a prior specified behaviour/request/spec, or update it, or integrate it with other things. Honestly, in my experience, the opposite is true of unit tests. I've never been able to make a significant change to a piece of code that was thoroughly unit tested without having to more or less re-write the unit tests from scratch. However, integration tests and…

I'm not completely convinced of exhaustive unit testing either as an end in itself. I also haven't been writing tests regularly for that long but I did extensively test quite a large surface with a game I'm writing for a long time in the past months but there it's also not exactly unit tests what I did and more verifying that actions produced the expected results and, where it was easy, also making sure some obvious side-effects were not part of the result.

Besides that I also haven't been thrown into codebases where I had to refactor in anger someone else's code or tests, I imagine it can get very frustrating as well when overdone or done badly (and not saying I wouldn't do it badly either - I think it can be easy to overdo unit testing without any relevant gains).

I guess what I'm leaning towards in my own practice though is thinking of unit tests as trash-able. That is, if you want to, using them to drive the design and verify along the way the small parts that comprise whatever end API (in the library sense not REST, even if it's just part of your "code" and not a library in itself) you're designing it's ok, if that makes sense to your development style, but once you have the API in place the important thing is that the API itself is kept under test.

At that point if the unit tests become a burden they should be trash-able, as long as the API - I imagine what you mean by integration? - is kept tested. I don't know if this flies in practice if you're working in an environment that requires unit testing for everything and what not or if it's actually better to loose the time and re-write them - annoying as it might be, they usually indicate that something is broken if they're failing which can be better than being oblivious.

All of this though must also be regarded in terms of what is the "unit" we're referring here to and I also think different languages and ways of organising programs can change a lot the way one sees units, apis, etc. Some languages you have more of a domain like organisation where you set up APIs to "reach" to the underlying stuff, that probably means a unit in those languages. Others that are inching more towards a "lower level" generate what looks like much smaller unit definitions - which would probably be very annoying to test extensively - sometimes looks like people talk about unit testing and one is using ft and the other m without having defined the unit of measure.

Re: Best practices can slow your application down

#187

Post by kcartlidge »

dustinmoris wrote: post #177
kcartlidge wrote: post #171

Earlier quoted context omitted.

> The best practice would have been to build the parts which matter most in a language which allows them to be blazingly fast and write nice testable and easy to understand code. Something like Rust or Go. But no, they stuck with C# for god knows what reason Whilst for work I've done approaching two decades of C#, for my own stuff I have largely used Go for years now so I'm far from an MS apologist, but that impressi…

> Go-like performance, Java-like power, and Ruby-like simplicity You massively overestimate C#. Microsoft devdiv marketing is working.

> You massively overestimate C#. Microsoft devdiv marketing is working.

No, I don't. And it isn't based on marketing.

I've done C# since around 2001 and Go since around 2015 (in both cases tools, sites, and APIs) so my perspective on relative performance is from first-hand knowledge.

As regards Java I don't think the comparison is controversial, and I've done Ruby (and some Rails) on and off for many years and whilst some of it may be down to familiarity, I still find C# (after acclimatising to the .Net/Core Framework) to be equally readable, flexible, and simple.

You're totally free to disagree of course, I'm just taking the opportunity to correct the impression that I'm "overestimating" C# based on marketing when in reality there's no estimation happening at all - I'm speaking from personal experience.

Post reply on HN