Understanding Chaos

[logie17]

The situation is you inherit a project which has a history of 10 years of programming from many different programmers. The majority of the software is using object oriented principles. You're trying to sort out how objects relate to each, the class structure, and how the beast is able to stay alive. What tips out there with Perl do veterans have to try to understand how such large plates of spaghetti function? I have leaned heavily on the caller function and Data::Dumper. What are the suggested power tools? Anything to help generate any sort of UML type pictures? How can I find out what methods are availble to an object?

[Old_Gray_Bear]

The Perl Debugger (perl -d) is your friend. The 'm' command reports on the various methods available to an object; use it just after you have instantiated the beast --

my $obj = Class::new();
  DB<1> m $obj

'T' gives stack trace information and tells the context the routines are called in. I also use 's' step into method calls and then explore with 'w' and friends to see where I really ended up.

In terms of graphics, I have yet to find something that beats pencil and paper for the fine detail, white-board and Visio diagrams for the over-all structure. And Document Everything! Build POD, ReadMeFirst files, Twiki pages, what ever make you comfortable. Even if you don't have to come this way again, someone else will.

[adrianh]

What tips out there with Perl do veterans have to try to understand how such large plates of spaghetti function? I have leaned heavily on the caller function and Data::Dumper. What are the suggested power tools?

I find Devel::Cover a great exploratory tool for unknown code. Write some tests that exercise the functionality you're interested in. Look at the coverage output to see what code was touched.

Anything to help generate any sort of UML type pictures?

For the automatic UML rendering try UML::Sequence and UML::Class::Simple.

[renodino]

You may find UML::Sequence of value to figure out who's doing what to whom and when. philcrow wrote up a nice article on its use; it (kindof) supports reverse engineering Perl code, but YMMV.

[diotalevi]

I wrote Devel::Spy to instrument how data is accessed and used.

[GrandFather]

Various IDE's provide 'code' browsers that show some sort of overview of modules, packages and methods.

I use Active State's Komodo which shows a tree including the contents of any open files with information pertaining to 'Uses and Requires', Variables, Packages and members indicated with different icons in a cascade that reflects nesting. Double clicking on a node in the tree shifts focus to the appropriate element in the code. Such facilities are pretty common in IDEs generally.

[Zaxo]

Although OO was invented to prevent it, there is no principle which stops OO code from degenerating into a Big Ball of Mud when sufficiently ill-managed.

It's pretty well documented that when code is both sour and essential, essential is what counts. You have to keep it working because it's a critical node in your business. A ten year history suggests that that is the case.

Spaghetti code is usually untangled by refactoring procedures. I think that wild OO code should be tamed by reducing data structures. Having not seen your code, I have no assurance I'm right.

[planetscape]

I generally recommend the following nodes:

• Analyzing large Perl code base.
• Becoming familiar with a too-big codebase?

More such links are available at Reverse Engineering Stuff.

[adrianh]

What tips out there with Perl do veterans have to try to understand how such large plates of spaghetti function?

Two books you might find useful are Perl Medic and the (not Perl specific but still a bloody good book) Working Effectively with Legacy Code.

[dragonchild]

1. Write tests.
2. Refactor a tiny piece of code.
3. Verify tests pass.
4. Go to 2.

UML and the like are for managers. If any given piece is too big to hold in your hold, that means the piece is too big.

[adrianh]

UML and the like are for managers

I know where you're coming from - but UML is just a tool. It can be used well as well as badly. While I don't agree with everything Scott Ambler says the agile modelling approach is vaguely reasonable.

If any given piece is too big to hold in your hold, that means the piece is too big

Yup. And sometimes the best way to make it less big is to be shown a map. I know I end up scribbling stuff on whiteboards on occasion when presented with a big ball of mud. Some of them even (gasp) closely resemble UML.

Drawing and using UML diagrams doesn't mean you have to fall into BDUF RUP hell :-)

[derby]

Hey! When did my company hire a new dev and why didn't anyone tell me!

Okay .. Data::Dumper and the debugger are good starts as is Log::Log4Perl. I've seen articles about producing UML type diagrams (or more likely, call trees). But if you have a big ball of mud, the picture will not be pretty.

[DACONTI]

Hi logie17
I had this problem few years ago with a job scheduling software and I managed it!
I used following principles, I think some of them could also apply for your case:
1. Instead of trying to understand the code I tried first to understand what it was doing.
In fact by quickly evaluating the nr of code lines, the techniques used and the style of coding I saw that it was impossible to understand the code in a finite time.
2. I prepared myself dummies to simulate less important modules (in this case the scheduled jobs). In this way I got a substantial easier complexity to manage.
3. When I had to change something I took just whole functions away and rebuilt them new.I studied only poorly the code,instead I concentrated my efforts more in understanding the requirements.
Because who says you that existing procedures are really implementing correctly the required functionality?
4. I was testing a lot, and I took care to optimize test runs.
But finally I can only say to you:
Good Luck!
Regs,
DACONTI

[shmem]

What are the suggested power tools?

An extremely helpful powertool is Data::Dump::Streamer, since it not only outputs data structures or code, but nearly all bits necessary for an object to exist.

Read more... (5 kB)

[shift8]

there is a semi-functional extention to doxygen that can grok perl: http://www.bigsister.ch/doxygenfilter/ - Devel::XXX, perl and grep for instantiations, function defs and calls and make pretty html out of it. robodocumentation is out there. also Komodo from activestate will let you step through code like other debuggers but with a more graphical nature.

[wjw]

One other notable debugger which I have found to be useful when a komodo license is out of the question, and Devel::ptkdb is not viable (you don't want all the Tcl/TK junk lying around), and you have *nix/cygwin available: DDD -> here if your interested.

Good luck with the pasta, if you get discouraged, think of what your doing as making the sauce. That is what takes time and gives flavor, and palatability.. :-)

[Moron]

Also, you'd be surprised what has been documented. I often find myself doing a Windoze search for documents containing any of the names the project went under over the period in question (system names can change over time). Also check for whether at any time the software has been kept in a version control system such as cvs on *nix or SourceSafe on Windows.

It might be possible to fill in missing links in its evolution rather than attempt to reverse engineer functional and technical designs from scratch which, over ten years, might be impossible.

I might be telling you what you already know, but just in case: if it turns out you have overstated your goal, e.g. someone pulls out a pile of documentation and says, "what do you mean? Here it all is!", the business case for the time you spend on a full reverse engineering effort is liable to implode with collateral damage.

[Grey Fox]

logie17
I usually use Perltidy to put the code in some kind of order before I try to understand the old code. This usually helps me find out where to put the debug statements I need.