Friday, February 27, 2015

On good enough code

So what is good enough? 
Too many posts have passed without answering this obvious question.
Let me see the code. Let me ask you a few easy questions.
  • Does it work?
Did I get you on the first hurdle? I hope not - but I've seen it too many times.
  • Can I understand it? Even without thinking?
It is a code review, not deciphering contest.
  • Is the structure clean and consistent?
Use similar name for similar things. Use different name for different things.
  • Is it consistent with the rest of the project?
How does your change fit into the rest of the project?
  • Are infrastructure parts separate? Reusable?
Hardly ever you will be able to reuse your business logic in a different project. But you can often reuse infrastructure. Or - if structured correctly - parts of it.
It is not necessary to always split everything into packages. But it should be simple to do later. 
  • Do you have automated tests?
I don't like to set a target coverage. Test as much as is reasonably possible. Aim for 100% on any logic. Keep untested parts small and simple. I prefer functional tests using BDD over pure unit tests.
  • And speaking about tests - do they really test enough?
Too often I have seen tests which did not test much. If the test method is called something like TestCalculate it is immediately suspect. 
Coverage analysis does not help you with this. It only tells you what is run, not what is verified. Test driven development helps a lot. 
  • Can it be refactored easily?
Refactoring is a necessity to keep code in a good shape. Requirements will change. Bug will be found and fixed. Your code needs to be ready now. 
Did you answer yes to all of these? Congratulations, your code have a chance  to be good enough. No? Get back to a drawing board, this needs some improvement.

No comments:

Post a Comment