3 ms·
Same here, and also: 1. Good modular design is easy to write unit test for and doesn't require design pattern contortions. New is not a modern day plague to be
by biohacker42 18y ago
Same here, and also:
1. Good modular design is easy to write unit test for and doesn't require design pattern contortions. New is not a modern day plague to be avoided at all costs.
7. and 8. Taking things too far. You can not get a good design with a lot of hard and fast rules. But you might avoid terrible, impossible to maintain code. I think I see the problem now, google is about managing a whole lot of average coders, not great hackers.
Not the best software writing, kind of enterpise-ey sounding.
I also detect a hint of someone writes code, someone else writes test for it - BAD. Unit tests should be written by who ever wrote the code that is being tested. Preferably unit test first, then code.
- ajross 18y agoMaybe I'm just charitably interpreting things, but #1 actually seemed OK to me. I think his point was that you want to separate the code that interprets your data from the code that builds your data so that they can be tested in isolation. That makes a lot of sense to me. The "bad code" end of this spectrum would be an algorithm in the application logic that can only run when connected to a fully-stocked external data store. That's not very testable; ideally you want to suck in a "test set" from a file or whatever and hand it to the algorithm instead. But yeah, it's not as simple as removing "new" calls from application logic; it depends entirely on what you're trying to construct.
- biohacker42 18y agoMaybe I've just seen one too many factory factories.