On 7/21/2016 11:49 PM, Booth Martin wrote:
Fair comment Buck. First, my experience with sub-procedures is limited,
so there is confusion on my part. Bear that in mind as you try to
figure out what I am asking.
I have worked with sub-procedures in different shops. One problem
seemed universal. Each programmer had his own set of sub-procedures.
Was there overlap? Yes. But then, not really. Each sub-procedure was
just enough different that when it came time to use an existing
sub-procedure, it was almost just right, but not quite. After a few
years there is various libraries, various slants on the same problems,
and an overwhelming pile of sub-procedures to plow through to find one
that one could use in a current project.
This is an interesting problem. The proximate cause of 'each programmer
had his own set' is that each programmer works in isolation. Enough
isolation that his first thought is not to go looking for code that's
already in service, nor to ask a colleague, but to simply 'do it myself'.
There's a subtle interrelationship between this isolation and 'just
enough different'. First, I write my sub-procedure to solve /my/
immediate problem. And because I don't confer with colleagues, it
doesn't occur to me to expand the sub-proc, to make it generic enough,
that it can be considered part of a general code library. So if a
colleague does manage to scrounge through the code base, my sub-proc is
just different enough that she's unlikely to be able to use it. And
because it's deployed, it's also difficult to change the parameter list.
So a new sub-proc gets written, specific to her needs, without
conferring with colleagues and the cycle continues.
Much of the 'overwhelming pile of sub-procedures to plow through'
problem simply goes away if we'd only ask our colleagues what they
suggest for problem X. Who knows, they might recall a function they
themselves wrote? And with a little bit of care, the use of CONST/VALUE
and *NOPASS, and 'thinking like a BIF', that sub-proc might get turned
into a general purpose function which we all can use.
I've seen cases where a programmer wrote a literal replacement for
IBM-provided BIFs like %trim() because she didn't confer with the RPG
manual. Didn't realise that /IBM/ had code that would solve problem X.
So I'm not personally convinced there's an issue with deploying
functions / sub-procs per se; I rather think it's the nature of many IBM
i shops to be insular, to DIY rather than buy off the shelf. Or reuse
off the shelf.
One thing which has really, really helped me to make my sub-procedures
more generic, more general purpose, is to use RPGUnit to test all of my
sub-procs. That helps me because it causes me to write each sub-proc in
such a way that it can be tested in complete isolation from the program
where it will eventually be used.
midrange.com
