good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re: Reading Someone's Programby sundialsvc4 (Abbot) |
on May 18, 2011 at 19:33 UTC ( [id://905548]=note: print w/replies, xml ) | Need Help?? |
I am in the wretched thick of just such a project right now. The code is horrid. One key practice for me is to make one code change at a time and to do it in a (git ...) separate branch. This makes parallel sets of changes which are more-or-less tagged to why I made them. I am also keeping a “running log” – a diary – of everything that I am doing, and I’m making the entire team do the same thing. The “Dealing Effectively” book, mentioned earlier, is one that of course I have looked at, but, having looked at it, didn’t buy. I felt that it might be “the cat’s meow” if you happened to have stumbled upon a bunch of object-oriented code that just wasn’t quite up to snuff, but it had very little practical advice to offer with regard to the large mass of existing (true “legacy”) code that wasn’t built that way. Be wary of “change for the sake of change,” or what a former colleague of mine once called, “making it ‘–er.’” You need to familiarize yourself with the code very thoroughly, and then consider what is the least intrusive set of changes that must be made in order to satisfy the new requirement. Sometimes that isn’t the right approach: sometimes the thing is so near dead that you have to grab the ol’ defrib paddles and shout, “Clear!” But just remember that, if you blast the thing apart, you still have to put it all back together and send it running down the road at sixty miles an hour ...
In Section
Seekers of Perl Wisdom
|
|