Breakfast wrote:So I'd like to know how individuals familiarize themselves with an existing code base of any size. Are there specific steps that you follow? What is your thought process behind choosing those steps and also the thought process that you use when carrying out those steps? How long did it take you to develop these skills and how long does it take you to progress through your steps?
well, here's, exactly, the process I used for my last major refactoring.
1. Start supporting the code. Take care of bug fixes. When I fix a bug, I generally introduce an automated unit test to verify the fix.
2. Start adding features to the code. When I add a feature, I generally introduce automated unit and behavior tests to verify the feature.
3. From steps 1 and 2, trouble spots naturally start to jump out. I never refactor because "that's not how I would have done it". I only refactor if the code is a significant source of bugs, requires a significant percentage of QA effort (from yourself or others), or is generally making itself a nuisance.
4. Write automated unit tests, behavior tests, and integration tests (if trivial, stubbed if not... calls to a local DB, trivial; calls to a remote queue on an AS/400, not) that are green against the code I'm going to refactor. Then, refactor and ensure the unit tests are still green.
This was on a fair (but not large) code base that had no comments and no unit tests. I supported it for 4-6 months and then rewrote it in my spare time over another month. I took it from around 120k lines with no unit tests to 17k lines including unit tests and significantly cut down the QA effort (partially because this actually recorded expected behaviors for the QA team and updated / made consistent the business requirements).
At my current job, a good chunk of what I do is greenfield development so it's less of an issue. For the parts that were inherited, I largely follow the same process as above just on a much compressed timeline (because the chunks I generally go after are much smaller).
A book I particularly enjoy is Refactoring to Patterns by Joshua Kerievsky. It might help with some situational refactoring help.