My credentials for writing this article stems from the fact that for the past 1 year, i have read more code than pages in novels (exaggeration intended).
With software maintenance becoming the bread-winner for service based companies, a software maintenance engineer (call him so for the lack of pure jargon) many times finds himself staring at unknown code. Faced with similar situations, i follow the following steps:
1. Firstly get your hands on design documents
Documents do help. If you are totally new to the project, getting the top level idea is the first priority. Try to get hands on as much related documents as possible. More information is GOOD. The first place to independently search for such documents is a decently maintained repository. Search through the piles of DOCs, PPTs and PDFs and you will at times be pleasantly surprised to find that some cherubic soul would have done all the hard work for you. Look for documents with general ideas. Say no to specifics. A large maintenance project usually will have lots of literature dedicated to brilliant bug fixes and employee knowledge transfer docs. You are here to create such docs not read them!
2. Get a companion to help you through the introduction
Project induction training is for a Renaissance man. But your job requires you to zero-in on your module as soon as possible. If you are lucky, your new colleague could help you out on a specific module of interest. Ask as many questions as you can about your module. How is the module designed? Are the design documents reflecting the actual software or are they relics already? What is the complexity level of the module? Ask questions from your point of view. For example, you might be UNIX master, try to correlate the new system with your old experience. This will give you familiarity amongst the unknown. These steps will give you a nice platform to start-off.
3. Get the right code to travel through
In a large maintenance project you don’t need to spend time and energy reading a feature in the code which has been culled long ago. Always get the right code which means the latest release code. Keep reality at the nearest.
4. Check the directory structure
Every project will have a directory structure that reflects its modularity. Modules are divided into repository element or directories. The same structure could again be followed within a complex module. Armed with the general structure of the software, go through the various directories of the repository. Within the module's directory look through each of the file headers of source and headers files for the little more detailed picture. Some files will be deal with module's kernel, others with utility routines, wrappers, inter-module interfaces and some others with do job at all. Getting acquainted with such information will help you in traversing the code later. The modules are never standalone and hence share files with other modules. These shared elements may lie inside the module's directory or someplace else. Iterations of code browsing will later reveal these elements slowly. Patience. Period.
5. Get a good source code browser
A good source code browser goes a long way in quickly ramping you up. A code browser like Source Insight is a very effective tool designed to be saviour for the code challenged. Forget VI, adapt.
6. Observe the data elements / control flows of the code
Step 1 introduces you to important data structures. Look for such elements. These are the structures you will have to be careful about, once code editing begins. Control flows will introduce routines and data handling techniques. Look carefully at the routines as you parse the code. Generally one can figure out the top level and low level routines easily after a couple of iterations of the code. Also the information gained in step 4 will help. The God may lie in small things, but nobody understands the entire code overnight by looking into details. Avoid looking into of complex calculations, code tricks intially. Instead go through multiple iterations of the code by incrementally increasing the detail level each time.
7. Prepare a call stack if needed for each control flow scenario
This activity can be clubbed with step 6. Recognize a scenario when control within the software moves from point A to B. Traverse the flow and note down the routines that you encounter. Next time when you are thinking about when a particular function is call, the control flow will strike you first.
8. Make use of the real system to learn
If the trainer happens to walk you into the lab after the project training, your learning process is in for a break. Looking at the actual system can sometimes trigger the enthusiast in one. Getting hands on the target system can make the code study a lot easier. If the target has debugging features to work on, the process can turn out to be fun. Break points, single steps, stack tracing facilities can be used as effective learning tools.
No comments:
Post a Comment