On 31 August 2015 at 18:32, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
Yep. I no longer need a TODO after I've done it :-) ...when I've actually
written the implementing code, I simply delete the TODO comment.
This makes sense - someone on the net suggested creating a 2nd task
identifier, DONE, and replace TODO with DONE in the code. Maybe, eh?
And only now do I really understand what you're getting at. Honestly,
some days I'm as dense as granite. You want a tangible task list
where you can see what's been done and what's left to do all in one
go. I can definitely see where that's valuable, and perhaps Mylyn
will help me realise that. I've installed it but not really got the
hang of it quite yet.
The reason I don't need that sort of a checklist is kind of a long
story, but essentially my boss doesn't keep that sort of tabs on me.
She lets me deal with the code on my own terms. Not that it makes
sense for anyone else, but to give you a sense for how my day goes...
Say I need to implement a new function: answer the question 'Did the
customer give us an email address?' I'll write a new sub-procedure
called doesCustHaveEmail, put one like of code in it; // TODO Does
customer have email
Then I'll start looking around for existing sub-procedures. In this
case, we have 3 places email can be stored (we play with the cards we
were dealt) and there's one sub-procedure that'll return one of those
addresses. So I write // TODO implement getCustContactEmail.
I have to check 2 more places, so I write // TODO getCustWebEmail and
// TODO getCustCeoEmail. Then I start writing getCustWebEmail so I
can get a sense of thc parameter list I'll need. In /that/ I write a
// TODO implement fetch email address from CMS. Then I go back to the
calling function and call the new stub and remove the TODO for that.
This leaves me with a 'working' program in the sense that all of the
function calls are in place, but all of the stubs return nil, normal,
0, blank, whatever.
The TODOs in these innermost stub functions guide me as to what I need
to work on, from a medium level view. I start implementing an inner
function by writing a test, then the code that satisfies the test. I
have a mental template I use for these initial tests: no input (ie
customer number 0), customer not found (hey, how do we tell the caller
that? Gets me cranking on error handling and reporting almost
immediately) Lately I've been adding tests for RCAC violations even
though we don't use RCAC in production. I feel bad that I don't
handle I/O errors in general very well and I'm trying to make up for
it. Maximum, minimum (negative customer numbers? After 37 years
nothing surprises me) I can't add a test that's specific to IBM i
authority violations, but I do that too. Only after I get the
'infrastructure' tests done do I start on actual implementation tests
and code.
After I'm satisfied that the code in this inner stub passes all the
tests it needs to pass, I pull the TODO for it and go to the next one.
Eventually, they all go away, as the work is done. Well, done enough
to release it to production anyway. It'll change: maybe today, but
that becomes another set of TODOs that I pop in the code.
When I'm in the groove, I don't drop many TODOs in the code I'm
working on, but I'll definitely put some into code that I am about to
get to. My mental processes are easily derailed, and I find that
opening up a different procedure (Ctrl-2 yay!) to put a TODO Ctrl-0 to
close it - this isn't distracting enough and I stay in the groove.
I guess after all that, I'm saying that I use TODOs as my personal
medium term aide memoire more than an actual task list. Sorry for
rambling.
--buck
midrange.com
