8

Yes, the dreaded 'M' word.

You've got a workstation, source control and half a million lines of source code that you didn't write. The documentation was out of date the moment that it was approved and published. The original developers are LTAO, at the next project/startup/loony bin and not answering email.

What are you going to do?

{favourite editor} and Grep will get you started on your spelunking through the gnarling guts of the code base but what other tools should be in the maintenance engineers toolbox?

To start the ball-rolling; I don't think I could live without source-insight for C/C++ spelunking. (DISCLAIMER: I don't work for 'em).

Ira Baxter
  • 88,629
  • 18
  • 158
  • 311
Simon Peverett
  • 3,855
  • 3
  • 28
  • 35
  • Vodka, Tequila, or Scotch work well – Danimal Sep 24 '08 at 14:44
  • Mh, that's a really typical situation with some OpenSource projects - writing docs isn't the favorite task of a programmer. I usually take my editor and start reading code backwards until I know what it does in the case it doesn't do what I expected. I usually hope it works completely. ;) – unexist Sep 24 '08 at 15:35
  • I'm a big fan of Source Insight too. Excellent editor with awesome symbol lookup functions. – Jonas Engström Oct 23 '08 at 23:06

12 Answers12

4

Just like eating the elephant - one bite at a time :)

Sometimes the big picture can be a real demotivator, and you need to pick a spot and tackle it piece by piece.

Of course, you still need to choose the bit to start on. Typically this is driven mostly by the users/business with top priority specific changes required (yesterday) but if you have a little flexibility or familiarization time, metrics are often useful. Tools here vary with the technology and language, but tools like NDepend and JDepend, any built in Code Metrics (like in in Visual Studio Team System, or the various available Eclipse plugins) or a tool like Simian to get a feel for the size of the copy and paste problem.

Hopefully the number of unit tests and coverage is greater than zero, and so a good first step is to always get whatever tests you can running in a Continuous Integration environment, as a foundation for adding more tests as you learn.

And as others have said - assuming options are available for the language - a good IDE with code navigation and automated refactoring is a must (Eclipse, Visual Studio with or without ReSharper).

A couple of morale-boosting books:

Good luck :)

Tanjim Khan
  • 556
  • 1
  • 7
  • 17
Matt Ryan
  • 1,034
  • 8
  • 9
3

One of the best tools in the .Net space is ReSharper. This tool has saved me time in all aspects of the development life-cycle. They have also helped me survive while joining undocumented project/solutions.

  • Code Refactoring
  • Code Navigation
  • Code Analysis

These are some of the many features which help one perform time consuming tasks.

Tanjim Khan
  • 556
  • 1
  • 7
  • 17
Alexandre Brisebois
  • 6,239
  • 12
  • 47
  • 68
2

Code search engines can help you find you way around a huge source base.

A language-sensitive source code search engine can be found at SD Source Code Search Engine. It can handle many languages at the same time. Searches can be performed for patterns in a specific language, or patterns across languages (such as "find identifiers involving TAX"). By being sensitive to language tokens, the number of false positives is reduced, saving time for the user. It understands C, C++, C#, COBOL, Java, ECMAScript, Java, XML, Verilog, VHDL and a number of other languages.

(I'm the tool architect)

Tanjim Khan
  • 556
  • 1
  • 7
  • 17
Ira Baxter
  • 88,629
  • 18
  • 158
  • 311
1

I usually start with Emacs + CScope on Linux. Visual Studio has some inspection tools that give you a similar capability for Windows. Doxygen can be pretty useful too - it will generate docs that can be useful even if the sources don't have documentation comments.

Ben Collins
  • 19,889
  • 16
  • 119
  • 182
1

I will run some UML tool (maybe simple notebook with a pen =) ) and/or tools for building classes, calls, methods hierarchies (integrated in IDE). Then I'll watch dynamics with debugger or simple unit tests. With this stuff I'll try to perform some kind of reverse engineering to figure out design.

Rorick
  • 8,561
  • 3
  • 30
  • 36
1

In such situations, I'd use Understand for C++

Xavier Nodet
  • 4,734
  • 2
  • 33
  • 48
1

Using a signature survey process is a good way to get a bird's-eye understanding of the code. With a good scripting language and some mojo to use it, building a highly customized signature survey for your own codebase in any language isn't a difficult task at all.

The bug tracking software, especially if it links up to your source control software will be invaluable, as it might give you some insight into why some poor decisions were made. This is even more important if the maintenance programmer plans on doing some refactoring as well.

A written log is also helpful, so that you can document the system as you go along.

Tanjim Khan
  • 556
  • 1
  • 7
  • 17
Jonathan Arkell
  • 9,875
  • 2
  • 22
  • 32
0

Yep, hit the nail on the head. A unix shell and the handy Notepad++ are what I used to use when I did maintenance work in ColdFusion, PHP, Perl etc. It is nice not to switch editors, and track down all references to a name/param/variable.

Now I just right-click and hit 'Find all References' in Visual Studio, which seems like cheating to be honest. The PHP guys are extremely jealous, as they are forced to use vi for editing. ;)

Tanjim Khan
  • 556
  • 1
  • 7
  • 17
willasaywhat
  • 2,364
  • 20
  • 23
0

The critical tool would be something that allows you to navigate (and edit) the code base to help your comprehension.

It is very useful to have something that can display the class relationship (if using OO language). The ability to display (static) call trees is also very useful when you want to gauge the impact of a change you will be making.

You mention source-insight. A long running open source project is source navigator. It looks like development has started again after being stagnant for a while.

Benoit
  • 34,830
  • 24
  • 79
  • 113
0

I find Lutz's Reflector useful for this, especially when you have a mix of code and binaries. You get call and dependency graphs (depends on, used by, exposed by, instantiated by, etc.), assembly graphs, and some great plugins.

Justin R.
  • 21,845
  • 21
  • 102
  • 147
0

You need to be able to navigate throughout the codebase. If your favorite IDE does permit this, then you can use a indexer such as Understand for C++ (already cited), lxr, or OpenGrok.

In a hurry, you can rely on grep(1s) or - better - Ack.

alanc
  • 3,921
  • 18
  • 24
philant
  • 31,604
  • 11
  • 64
  • 107
0

NDepend is a tool dedicated to re-engineer legacy code, especially large entangled legacy code bases Disclaimer: I am one of the tool developers

To quote Scott Hanselman who once wrote in his blog: "NDepend is giving me insight into my applications that I haven't had before (...) Once I realized the depth and breadth of the information I was looking at it, I was like a kid in a candy shop."

Some NDepend's features useful for re-engineering are:

Ira Baxter
  • 88,629
  • 18
  • 158
  • 311
Patrick from NDepend team
  • 12,441
  • 4
  • 53
  • 72