Best Tools for Software Maintenance Engineering

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).

From stackoverflow Pev

• Yep, hit the nail on the head. A unix shell and the handy Notepad++ is what I used to use when I did maintenance work in ColdFusion, PHP, Perl etc. Nice to not 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. ;)

  From Abyss Knight

• 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 when joining undocumented project/solutions.

  • Code Refactoring
  • Code Navigation
  • Code Analysis

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

  From Alexandre Brisebois

• 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.

  From Ben Collins

• 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.

  From Rorick

• 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.

  From Benoit

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

  From Xavier Nodet

• 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, still need to choose the bit to start on... Typically this is driven most 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 always to 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:

  • Michael C. Feathers: Working Effectively with Legacy Code
  • Martin Fowler: Refactoring: Improving the Design of Existing Code

  Good luck :)

  From Matt Ryan

• Using a signature survey process is a good way to get a very birds 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 whatever your 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 in to 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.

  From Jonathan Arkell

• 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.

  From fatcat1111

• 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.

  From philippe

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

  A langauge-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 langauge, or patterns across languages (such as "find identifiers involving TAX"). By being sensitive to langauge 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).

  From Ira Baxter

• NDepend is a great tool to re-engineer legacy code, especially large entangled legacy code bases. To quote Scott Hanselman that suggested once on 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. "

  The NDepend's features I prefer for re-engineering are:

  • Dependency Matrix / Graph, to understand the structure of the code.
  • CQL (Code Query Language) to ask the code base to give me its best secret (ask for dead code, ask for poor quality code, ask for not-encapsulated code...)
  • Diff on code base, to see what has been added/refactored/removed between any 2 versions of the code.
  From Patrick Smacchia - NDepend dev