It was a fun day. My tech lead just freaked out with the way I started to think - repetitive, narrowed and complicated. When you have a simple requirement to turn to code, I sat there generating data using code! When the use-case is to be tested, is it worth to sit and generalize code rather than taking sample data-sets directly? And what if, after hours of coding such a case, you find that it was fundamentally wrong?
After pissing out people, I crashed into test-driven development. I have no idea with it's literal intent is, but it might be to see if you write according to use-cases and not in a general fashion all the time. The approach simply rocks, as you narrow down to your need and not to any dependencies. No chains. Not to external factors. Just plain, functional development.
Always break the need to direct samples, not code for them
I totally irritated my senior here. He kept on insisting to use hard values but there I was, using the general data-set code. And then it boomed him off. Unnecessary complications of writing lines and lines of code can lead to a basic leak in achieving the purpose. Just take a simple set to begin with. It can be a HashMap, a Dictionary, an array or a list. Just that. And fill in random, hard-coded data.
Never code for random data! You may be handling a lot of data but not the intended data. And, you lose most of the use-cases.
Develop functions for samples. Generalize them later.
Instead of worrying about sample-generating code which won't be used at all later, why not focus on what objective you're intending to? The input set, operation(s) and the net result? There are implications in these. The use-case handling gets freakier. Change the samples, and the module behaves strangely. Add more lines inside, function crashes. Dependencies, external and internal blow up. And you thought input handling can do all of it. It was just the beginning.
Test, Test and er.. Test.
Module development isn't easy. You've to address all of the various issues. And the solution? Testing. Test your functions. Change inputs. Change behavior. Comment code in between, see the difference. TEST ALL OF IT MANUALLY!! Automate these only if you've time. Use asserts to crash. Check how your code can be integrated into the main system after achieving success and drinking beer.
And yes, test the main system after integration. The same old dependency problem, you see. And drink more to that.
Ask for help, even if you're a geek
Internet was never this friendlier before. Are you looking up the correct sources for help? Are you using too much of unnecessary thinking? Can a single line solve your problem? Direct documentation look up is waste. Nobody has the time to sit, understand and then use their brains to get the problem solved, unless there's no direct help. You might not be searching properly either. Helpers blame questioners for this sole reason.
The above should do your objective. Trust me, it cut down my working time to a quarter.
TDD, my style. Bye.