In the previous post, I covered the steps for preparing to really dig into a new project. Now that you’re ready to go, here are six steps that you might find useful.
- Get it running
- Do very high-level overview
- Dig into specifics
- Switch to clean backup or rollback with version control
- Cleanup unused code
- Fix some small bugs or issues
Get it running
I’m assuming you’re doing development on your local machine, so the first step is going to be getting the project running correctly. In part 1, I emphasized the importance of having a reference copy so you can tell the difference between config issues and things that are just broken. Get things setup, compare to reference copy, run through some user flows on both sites, and make sure you’re all set.
Do very high-level survey
I start with the basics, like where are the various config files, does it follow MVC or another design pattern, what’s the basic flow from file to file, etc. This is usually accomplished by tearing up the code, throwing debug statements around, etc. Take lots of notes, and add comments to files as you figure out what they do and why they’re there.
Dig into the specifics of the code
Once you have the higher-level stuff, try to figure out the core of the app and how it works. There are common things that most sites have, like authentication, but most projects have their own special sauce that’s unique. Sometimes it’s for good reason, often not, but you’ll need to understand it. Figure out what’s unique about this project and spend some time really mucking with the code here. Put in lots of comments and debug statements, and really try and understand the rough outlines of what the code is doing.
Switch to clean backup or rollback with version control
Depending on the damage you’ve done to the code, you might want to go back to a clean copy of the code, or revert your changes using whatever version control you’re using. However, this does mean you’ll lose those comments you made, so it’s a judgment call. The alternative is removing all your debug statements and other changes, and running through the app to ensure you haven’t introduced new problems.
Cleanup unused code
I hate code clutter. There’s nothing worse than starting a new project and seeing things like this:
- functions.php
- functions2.php
- _functions.php
- functions_by_brad.php
- functions_new.php
- old_functions2.php
Equally bad are files where 75% of the code has been commented out and just left hanging around. These are all consequences of not using version control properly. If at all possible, put the project in version control, figure out which of these files is currently in use, and clean the rest of this cruft out. This is optional at this stage, and sometimes I wait until later in the project when I’m more familiar with what goes where.
Fix small bugs or issues
Now that you’ve got a good high-level understanding of what’s what and how the program execution flow goes, and maybe even cleaned up some stuff, it’s time to add your own mark. I like to start with small bugs. The smaller the better, because you’ll spend time looking for where to make a small change, which gives you better understanding of the code. Big changes at first can leave you feeling overwhelmed. So look at the list of bugs or features that the client has provided and try to sort them in terms of anticipated difficulty and tackle the first couple that seem like a snap to fix.
You’ll know the project like the back of your hand in no time.