Organic Produce
Sometimes it seems to me like my code grows organically.
I start programming, and when I've got whatever I'm working on to work, I notice redundancies in different parts of my code. Then I start to think about how to abstract those parts, like taking one particular sequence of function calls that occurs at several places, and putting that in a function of its own, which I call from all those places. This makes the calling code shorter and more readable, and more often than not improves reusability, because when somebody wants to add functionality in that particular feature, they just have to deal with one function call (which, if using sensible parameters, is going to fit their requirements).
The way I do this seems natural to me—I could also contend that learning from first hand experience is better than excessive planning beforehand. We all know functions that ended up being impossibly tedious to call because they were over-generalized and were designed to cope with every present and future eventuality, most of which failed to materialize, ever. I've seen this most often with design by committee, where everybody has great ideas, but nobody has the sense to say, stop, we've gone too far.
Anyway.
What I can't deny, though, is the fact that those situations seem to arise more often when I don't plan much beforehand, because a) the problem seems trivial, and/or b) I feel I already have a pretty good idea how I'm going to solve it. So this may just be a consequence of my lack of planning, meaning I'd have discovered the redundancy and potential for abstraction during design, had I taken the time to do any.
I'm still not sure what the answer is. It may lie between the two extremes. One lesson to take away for sure is this: Always, always plan ahead. Even if it means just sitting down for half an hour and going over how you intend to solve the problem in your head. Because, and I can confirm that from personal experience, the amount of time it takes you to fix a design mistake during coding is greater my an order of magnitude than the time it would have taken you to fix it in design.
I start programming, and when I've got whatever I'm working on to work, I notice redundancies in different parts of my code. Then I start to think about how to abstract those parts, like taking one particular sequence of function calls that occurs at several places, and putting that in a function of its own, which I call from all those places. This makes the calling code shorter and more readable, and more often than not improves reusability, because when somebody wants to add functionality in that particular feature, they just have to deal with one function call (which, if using sensible parameters, is going to fit their requirements).
The way I do this seems natural to me—I could also contend that learning from first hand experience is better than excessive planning beforehand. We all know functions that ended up being impossibly tedious to call because they were over-generalized and were designed to cope with every present and future eventuality, most of which failed to materialize, ever. I've seen this most often with design by committee, where everybody has great ideas, but nobody has the sense to say, stop, we've gone too far.
Anyway.
What I can't deny, though, is the fact that those situations seem to arise more often when I don't plan much beforehand, because a) the problem seems trivial, and/or b) I feel I already have a pretty good idea how I'm going to solve it. So this may just be a consequence of my lack of planning, meaning I'd have discovered the redundancy and potential for abstraction during design, had I taken the time to do any.
I'm still not sure what the answer is. It may lie between the two extremes. One lesson to take away for sure is this: Always, always plan ahead. Even if it means just sitting down for half an hour and going over how you intend to solve the problem in your head. Because, and I can confirm that from personal experience, the amount of time it takes you to fix a design mistake during coding is greater my an order of magnitude than the time it would have taken you to fix it in design.
posted by Tobias Klüpfel at 9:13 AM
0 Comments:
Post a Comment
<< Home