Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

best way to understand existing perl code

by balakrishnan (Monk)
on Aug 08, 2011 at 09:50 UTC ( #919182=perlquestion: print w/replies, xml ) Need Help??
balakrishnan has asked for the wisdom of the Perl Monks concerning the following question:

Hi folks,

Please suggest the best way to start understanding the existing perl project code

  • Comment on best way to understand existing perl code

Replies are listed 'Best First'.
Re: best way to understand existing perl code
by Perlbotics (Chancellor) on Aug 08, 2011 at 10:13 UTC

    I assume, you were assigned to jump into the cold waters of maintaining an existing project?

    I would start to find answers to the following questions:

    • Who has maintained the code before? Is (s)he available for a walk through/introduction?
    • Where is the documentation? Does it exist anyhow? Is it up-to-date?
    • Where are the sources? Are they version controlled (e.g. learn from commit statements)?
    • Where are the tests? Studying them might give some insight...
    • Are there other tools (editors, xref, etc.) that can aid?
    • Where is the test- or staging-system (to experiment w/o endangering production)?
    • What is your boss' concrete expectation? (your task description)? Derive a small feasible but concrete task to start fiddeling with the code base.
    • ...

    Finally, for some people the learning by osmosis principle works. Skim through the sources, skim again, take notes while doing so. Finally, you'll have a mental map where to find something and how the pieces are connected to each other. Write new tests if you miss something or want to understand certain aspects. Experiment, but be sure you can undo your changes (e.g. version control).


    Update: Additional PM resources:

    I am not aware of a book that covers the topic of assessing an existing project. Maybe McConnell / Code Complete, Martin / Working Effectively with Legacy Code, or Fowler / Refactoring: Improving the Design of Existing Code might have some helpful sections about it? Conway / Perl Best Practices might help you help the next generation (people that take over from you).
    (in response to 919191)


      Thank you very much for your quick response.

      Can you give any standard book reference or other material to get into it further ?

        Peter Scott's Perl Medic is an excellent resource, if you're already moderately proficient with Perl 5.

Re: best way to understand existing perl code
by Ratazong (Monsignor) on Aug 08, 2011 at 10:04 UTC

    That depends on the code and on how "deep" you need to know it... I propose the following order:

    1. read the documentation (user manual, requirements, architecture, design)
    2. try to understand the related module-testcases
    3. read the comments inside the code
    4. read the code itself
    5. execute the code with debug-output, possibly alter the code and determine why which module-testcase fails
    If the documentation is sparse, you might use re-engineering-tools like doxygen, or this resource for regular expressions.

    Good luck (especially if you don't have documentation nor comments ;-)

Re: best way to understand existing perl code
by moritz (Cardinal) on Aug 08, 2011 at 09:58 UTC

    Learn perl, read the code, run the test suite, get familiar by conducting small changes (for example bug fixes).

    Do you have any more specific problems?

Re: best way to understand existing perl code
by DrHyde (Prior) on Aug 11, 2011 at 10:25 UTC

    Pair for a fortnight with someone who already knows the code. Have someone take you through the whole lifecycle of a few typical interactions between your project and the rest of the world. That's what got me started on the huge project that I currently work on. It only got me started though, it was at least three months before I was comfortable enough with the codebase to have a good idea of what each of the major building blocks does. During that time, I fixed little bugs all over the place, read the tests, re-factored stuff.

    If it's a small project, read the docs, read the code, and read the tests. Then pick something to fix or improve.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://919182]
Approved by marto
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (3)
As of 2017-06-26 05:33 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (572 votes). Check out past polls.