Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Understanding Chaos

by logie17 (Friar)
on Apr 21, 2007 at 18:48 UTC ( #611309=perlquestion: print w/ replies, xml ) Need Help??
logie17 has asked for the wisdom of the Perl Monks concerning the following question:

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?
s;;5776?12321=10609$d=9409:12100$xx;;s;(\d*);push @_,$1;eg;map{print chr(sqrt($_))."\n"} @_;

Comment on Understanding Chaos
Re: Understanding Chaos
by Old_Gray_Bear (Bishop) on Apr 21, 2007 at 20:15 UTC
    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.

    ----
    I Go Back to Sleep, Now.

    OGB

Re: Understanding Chaos
by GrandFather (Cardinal) on Apr 21, 2007 at 21:21 UTC

    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.


    DWIM is Perl's answer to Gödel
Re: Understanding Chaos
by renodino (Curate) on Apr 21, 2007 at 21:35 UTC
    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.

    Perl Contrarian & SQL fanboy
Re: Understanding Chaos
by adrianh (Chancellor) on Apr 21, 2007 at 21:35 UTC
    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.

Re: Understanding Chaos
by diotalevi (Canon) on Apr 22, 2007 at 01:27 UTC

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

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Re: Understanding Chaos
by Zaxo (Archbishop) on Apr 22, 2007 at 07:48 UTC

    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.

    After Compline,
    Zaxo

Re: Understanding Chaos
by dragonchild (Archbishop) on Apr 22, 2007 at 14:57 UTC
    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.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      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 :-)

Re: Understanding Chaos
by adrianh (Chancellor) on Apr 22, 2007 at 15:16 UTC
    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.

Re: Understanding Chaos
by derby (Abbot) on Apr 22, 2007 at 16:23 UTC

    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.

    -derby
Re: Understanding Chaos
by DACONTI (Scribe) on Apr 22, 2007 at 19:30 UTC
    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
Re: Understanding Chaos
by planetscape (Canon) on Apr 22, 2007 at 20:12 UTC
Re: Understanding Chaos
by shmem (Canon) on Apr 22, 2007 at 20:45 UTC
    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.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Understanding Chaos
by shift8 (Novice) on Apr 22, 2007 at 21:32 UTC
    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.
Re: Understanding Chaos
by wjw (Curate) on Apr 23, 2007 at 03:51 UTC
    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.. :-)

    ...the majority is always wrong, and always the last to know about it...

Re: Understanding Chaos
by Moron (Curate) on Apr 23, 2007 at 11:25 UTC
    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.

    __________________________________________________________________________________

    ^M Free your mind!

Re: Understanding Chaos
by Grey Fox (Chaplain) on Apr 23, 2007 at 19:38 UTC
    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.
    -- Grey Fox
    "We are grey. We stand between the darkness and the light" B5

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://611309]
Approved by McDarren
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (10)
As of 2014-12-22 04:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (110 votes), past polls