Over the past few months I’ve become quite a tool builder.
The project I’m currently on involves a lot of really repetitive code changes and analysis … basically I’ve been externalizing as much of the text in the product as I can (to message files). There are a LOT of display files to be analyzed … and this particular task looked like it was going to be very very very boring.
However … rather than trying to analyze each and every display file for text that can be externalized, I wrote a set of programs that would automate the process for me.
The first program read through each display file source member in a source file, parse the DDS, and write a file that contained the source member information; line number; text; length; and other useful bits. Obviously this program had to be aware of DDS continuation characters.
The next program would read through the file created in the first program and automatically generate messages in a message file that contained the text extracted from the DDS and recorded the generated messages id.
The final program in the set re-processed the source members … commenting out the lines where the hard coded text existed, and adding a duplicate line that replaced the text with a dummy field and the MSGID keyword (with the message id assigned to the text).
So now you’re thinking: Yeah, so? What’s your point?
My point is this … when you’re presented with a repetitive task that could be seriously mind numbing … consider making it more interesting by building a tool to do the job for you. Chances are you’ll get it done faster … and it will clearly be more interesting. You might even learn something along the way.
As more tasks on this project are assigned to me … I always try to figure out if a tool would get the job done faster. This has been the case more often than not.
Just for this project, I’ve written additional tools to …
- Convert single byte Japanese text to double byte Japanese text.
- Identify compile time arrays in RPG programs (not convert them to messages though)
- Compare two message files for additions and changes
Each tool presented it’s own set of problems … and ended up being quite engaging to write.
I like this approach. Over the years I also have been doing exactly the same. I prefer to invest time on build a tool that can parse out and change programs rather than: Search + Get a List + Modify hundreds and somethings thousands of programs.
Even if you take 3 days building a tool like that to save three days of manual work, you’ll know more about the language, you will know more about your legacy code and I guarantee that will be more fun. In the other hand, repetitive manual work on dozen of programs is always bugs risky, while if you have a program that change programs the results will be ‘accurate’ and ‘precise’ 99.9% of the time.
At the end, you’ll not need an army to make massive changes, the changes will be done quicker and the best of all is that the Quality Control process will be smoother, if you get the most complex programs and they are perfect you’ll find just little issues here and there.
Of course, I also generate a log of those changed programs, with the line before and after the change as reference.
Don’t forget to make your testings on a copy of the source file of a library!!