You are not alone. Throughout my business life I have worked with old code written by someone else (To be honest, I've hardly ever written new code).
As others have recommended, a good set of tests is absolutely necessary for such a refactoring. Old code is often battle hardened: It covers some edge cases in ways which are hard to understand because back then it seemed to be the easiest way to fix a long forgotten bug. Probably you'll need to write a lot of tests before even writing the first line of your new code.
I also recommend to refactor only when you have a concrete goal in mind: Some new feature, better security, whatever. Don't write the feature right now, but think about how you would like to integrate the new feature, if only the old code would allow it. Then refactor the relevant parts of the old code, still without changing its behavior - and only when you're done with that, add the new feature. Or, in other words: Don't refactor just for the fun of refactoring. Subroutines with more than 100 lines aren't immoral.
The details depend on the ecosystem of the code:
- Does the code have a test suite? Unit tests and/or application tests? Good. Still, add your own tests. This will go a long way to understand the old code. The test coverage can also be helpful to decide where to start.
- Do you have a source code repository? Good. Does it contain good commit messages? Even better. Reading those together with the old code can help to avoid re-introducing bugs, because that's really embarrassing. If your code dosn't have a source code repository, start one. Also, grow the habit to write good commit messages: If you are new to the code, you might want to revisit your first decisions when you're more familiar with it.
So, to sum it up, my recommendation is: Don't focus on the code alone. Improve the ecosystem as well: Documentation, tests, tools. If the old code is still relevant (why else would you have to work with it?), then there are chances that you need to pass it to someone else in the future.
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:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, 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, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||