While at Motorola, I rebuilt (practically from scratch) a system called BOOST, which was used for 90% of all sub-system, system, and regression testing of the software used in Motorola's CDMA base stations. I inherited this system and it was a mess when I got it. I left it in a very beautiful OO state.
Strategies? Your basic refactoring strategies, I guess.
- Get everything to run under strict.
- Identify common code that seems to be repeated and get it to live in one place.
- Identify bits of business logic that should live together, then make them live together, preferably in some object.
- Identify bits of application logic that yadda, yadda, yadda.
- If there's a way to make Perl do your work for you, then be intelligently-lazy. For example, all the messaging was done by having each message be its own class. But, I didn't want to maintain 1000+ messages in three different strains by hand. So, I developed a common data structure that would be inflated by Perl into the classes. (That was over 75% of the code and about 45% of the success.)
- Build a logging methodology and put it everywhere. Unless you know exactly what went wrong, you'll never make it right.
- Get the buy-in from your group leader, but ignore anyone higher. All they want to know is that it works, not the cool things you did to get it there.
- Write migration tools. Part of this effort involved changing the configuration files that the userbase used. Absolutely necessary. However, if I wanted acceptance, I had to make it as painless as possible to migrate.
Mistakes? The biggest mistake anyone can make is to not have a design document, preferably coupled with a requirements document. This isn't an ivory-tower nicety. This is a real-world, in-the-trenches, life-and-death necessity. Spend the 100 hours to make one and you will recoup that 100 hours in the next four weeks. (In case you think I'm exagerrating, ask Elian what he thinks of design documents.)
------
We are the carpenters and bricklayers of the Information Age.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.