Recently, I have been put in a challenging position of having to do short gigs on three projects that have been mostly dormant for a significant period of time. Additionally, they have been using technology stacks that I am not all that savvy in. While this has been difficult and frustrating, it has also been a fun challenge and allowed me to hone my skills in the area of project resurrection.
Resurrecting a Development Environment
In order to even begin, you need a solid development environment. When a project has been sitting on a shelf for a year or more, it’s likely that there have been significant changes in some of the tools, libraries, or even operating systems your project uses. While it may be tempting to start by bringing everything up to date, it is likely you will run into versioning hell due to API changes and other curve balls in the pile of technologies and libraries that were chosen when the project was originally created.
A package management tool is essential in capturing and maintaining the various libraries used in a project. Using a package management tool is one of the easiest and most responsible things you can do as a developer, including ensuring that the package configuration is checked into your source control repository for sharing and archival.
Virtual Box and VMWare are very valuable tools for creating and maintaining complete images of an OS (and environment) used for development. Additionally, Vagrant is an excellent tool for creating recipes for building virtual machines from scratch. This not only allows you to stash away these VMs with much less space, but makes it clear or at least discoverable what pieces were necessary on top of the base image.
Getting Your Debugging Fu On
When switching back to a technology stack you haven’t used in a while, and especially when picking up a new one, an often unforeseen cost incurred in time, and of course money, is being able to diagnose a problem, and do it efficiently.
Familiarizing yourself with the structure of a project on disk, the design patterns used, and the project-specific terms used is a great way to start. It is also expedited heavily by linking up with a previous developer on the project, since the time savings in this area are HUGE!
IDEs and Inspection Tools
Debuggers are valuable tools, though become increasingly daunting when they are folded into large IDEs like Microsoft Visual Studio or XCode. Many developers try to avoid IDEs like the plague and use more archaic techniques for debugging so that they can use their own editors, like Vim, Sublime Text, etc. to at least remain proficient at writing, modifying and surfing a code base. Debugging can often be accomplished via command-line tools, or using an IDE only for debugging.
Old-School Debugging (e.g. print/log)
In lieu of debuggers and IDEs, the importance, simplicity, and ease-of-use of good ole’ logging and print statements is extremely valuable! No setting of breakpoints and watching variables is needed. It may take a little time to bisect the source of an issue or where some piece of state is changing, but the lower barrier of entry and common strategies make this old-school method very time/cost-efficient in many cases.
Hopefully when you dusted off your project, the previous developer(s) created and maintained a README, wiki page, or some level of developer-grade documentation. Otherwise, there may be a good dose of black-magic that needs to be rediscovered or plucked from others brains, if they are still intact and/or available to you.
As a courtesy to future developers, or even your future self picking this project up again a year or two later, keep the developer documentation up-to-date. Coming in to an archived project and running into and conquering pain-points suggests that you aren’t the only one who will run into the same issue. So document it!