There's some improvements that can be made about clean-code-javascript HOT 2 CLOSED

Hey Paul! Thank you for your thorough critique. I totally feel where you're coming from.

1. You're right, picking a bad abstraction can be worse than duplicate code. There are lots of worse things though you can do to your codebase than duplicate some code, such as deleting all of your files! I don't mean to be dismissive about your point though, I just think in the majority of cases that I've personally experienced, I've gotten bit by duplicate code more than I have bad abstractions. Having said that, I've seen and written many bad abstractions, that's why there's a section on the SOLID principles and tons more about making your code resilient and refactorable. We shouldn't have to choose between the two.

2. And having said that above, you're right we shouldn't have to choose between shipping and testing. We can do both! We sometimes find ourselves though sacrificing this aspect of development for meeting deadlines. That's never good! All in all, we can rephrase my piece of advice, but I think that making the language a little less emphatic and a littler drier, by saying "Excellent automated tests are key to constant incremental updates...", doesn't drive home the point. I'll think of something though!

3. Code coverage is something that's needed, I believe. It's a necessary but insufficient condition to a good codebase, which is why it's not a silver bullet. Martin Fowler goes so far to say, "Certainly low coverage numbers, say below half, are a sign of trouble. But high numbers don't necessarily mean much." I don't know if I agree with his latter point fully, but it is true that you can't expect a complete lack of runtime errors when you have 100% test coverage. For example, you can still have race conditions occur that don't happen in a test environment but somehow happen in production. You can also not write bad tests and still have complete coverage. I didn't make my point clear enough though, and for that I'm sorry.

I think it's easy to fall into the trap where we think about every corner case, and provide caveats for all. As with any advice, it's not going to be true for every single aspect of the situation described. This is a highly opinionated guide, based on a highly opinionated book. Not all will be universally agreed upon like I mentioned, but I really appreciate your insight. Thanks again for raising this, I'm going to soften some of these lines as they can potentially lead a few people astray and give them misplaced confidence! I still want to be very clear that duplicate code is bad, but if you find yourself in the terrible scenario where you have to pick an abstraction that isn't well thought through and lacks evidence, then choose the duplicate code instead.

from clean-code-javascript.

Thanks for your comments @ryanmcdermott - also, apologies for the way I originally phrased the title. Considering one of the points I made was to try to phrase something more positively, I could have taken my own advice there!

I'm in work now so don't have much time to go through all your points - if you'd like me to make the odd pull request to help out a bit, I'll see what I can do if I can get the time.

I do appreciate your efforts here - sometimes it's just a good thing to make it clear what the advantages are of doing such and such a thing. With every tool or technique there are advantages and disadvantages and trade-offs to be made. For example with the code coverage information, it may be good to outline the advantage it gives you, but to make clear how 100% doesn't mean "fully covered" - I can even provide some examples potentially...

Anyway, keep up the good work!

from clean-code-javascript.