Digging Into Inherited Code
Last Updated on Monday, 1 June 2009 03:42 Written by Steve Monday, 1 June 2009 03:42
I inherited a code base when I started at the Salesforce.com Foundation. If you’re a Salesforce.com Admin or consultant, you may find yourself in the same position. What’s the best way to come up to speed on a new code base? It can be a daunting process.
In one of my last projects at ONE/Northwest I started working on a very complex Salesforce implementation someone else built. There wasn’t any Apex or VisualForce, but the config was really gnarly. Getting my head around the record types, custom objects, and fields was a real bear. I saw some things I don’t like to talk about…
With my new job, the config isn’t particularly complex. There are relatively few objects and no record types. But there is Apex and some VisualForce. Here are the steps I’m undergoing to get my head around the code:
Put out any fires
- Make sure the code is under source control.
- Deal with any mission critical bugs, but remember you don’t really know what’s going on yet.
- Set up an issue tracker and get it ready to collect issues you discover in this process
Schedule a demo so that you have a short-term goal
- I was asked to demo the NPSP for the Boston user group only a week after I started. I said yes because I knew it would force me to get comfortable with it.
- If you can’t demo to real users, demo to someone who will ask tough questions and understands the business process well enough to make you sweat.
- If you can, build out your own demo org rather than using one that’s already built. You’re code may not be packaged, so this might not work for you.
Understand the application flow
- Read any user documentation you’ve got
- Talk to anyone available who was involved in the design so you can try to understand the intent of the application flow.
- Click through the UI to see what happens
- Take the time to document the application flow in a flowcharting program, like Visio or Omnigraffle–writing it down forces you to fill in the blanks
- Discover all the button overrides
- Find out where cool stuff is happening with Triggers and where it’s happening with a VisualForce page
Dig into the code and see how that application flow is accomplished
- Look at existing Workflow to see what processes are handled there
- Look at the code
- Start with triggers, this is where the action happens
- Take notes – update the application flow diagram with markers where Triggers fire
- Look at the existing tests for nods toward key behaviors
- Go back to workflow
- If your workflow is complex, write detailed tests to prove the functionality
- Just because you can write Workflow by pointing and clicking doesn’t mean it will be easy to understand the behavior without testing
Document what you now know by heart
- Someone will be inheriting this code from you, so think about what you just went through and be kind.
For me it feel like probing in the dark with little parts of the picture slowly becoming illuminated. Follow your instincts about what to dig into, but don’t go to ground in any one area until you have a shallow understanding of the whole thing. Probe into the darkest corners until there is enough light to know how scary it is, and then move on, shooting for the whole room to reach dusk, and eventually, bright light.
I think it’s fun, this process of discovery. It’s much more fun when the code you are inheriting is well-designed, like this code is. When it’s rationally designed, your life is much easier. You’ll still have lots of work to do, but it won’t feel like a giant tangle of yarn for very long.