When you write code, which approach do you take?
When you write code, which approach do you take?
Focus on writing clean code, refactoring as you go Focus on writing code quickly, and clean it up afterwards
Focus on writing clean code, refactoring as you go Focus on writing code quickly, and clean it up afterwards
If you know the domain you're writing for and feel confident that you can build at least an 80% accurate model first time, focus on clean code.
If you're not that confident and expect to make design mistakes that you'll correct along the way, focus on making it work first, then clean up the code.
It's the same for testing: Well known territory and confidence in your model? Write unit tests first. Otherwise write unit tests second.
If it's completely unknown territory, write a prototype first with no tests, validate your assumptions, then throw out the prototype and write as if you're not going to get an 80% accurate model.
Write a first version/prototype, to flesh out the details. See if it's even useful. Figure out where the tricky parts are.
Perhaps tear it down and write again. More likely do some wholesale reorganization.
Let it sit for a while. Use it myself figure out what's missing.
Go through again (this is now #3) and fix the problems, further organize the code, get friendly users to test it out and report what real users need. (I'm a sole developer with no QA.)
Start writing functional tests. I don't like unit tests as I think they are too low-grained and inhibit larger-scale rewrites. This usually resolves the final architectural issues.
Then use coverage testing to find out I've only got 80% coverage, so add those. These usually involve error handling, like input files in the wrong format.
(I make sure to write that code as part of development, because that's when it's easiest to think of possible input errors. But I don't write tests for them because the parser and even the supported format might easily change over the iterations, making tests a waste of time, when I know even simple line-based coverage testing can identify what needs to be tested.)
Then write the end-user documentation, which usually teases out a few more issues.
If I can, put it aside and come back to in a few months later. Seeing it later with fresh eyes helps as a code reviewer.
I've got 14,000 tests. Takes about 45 seconds to run the main tests. The full tests include some very lengthy tests that I rarely run.