best way to understand existing perl code

[balakrishnan]

Hi folks,

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

[Perlbotics]

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

HTH

Update: Additional PM resources:

• Becoming familiar with a too-big codebase?
• project structure / class browser for Perl?
• Analyzing large Perl code base.
• Code struct map building?

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)

[balakrishnan]

Hi,


Thank you very much for your quick response.




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

[chromatic]

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

[Ratazong]

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

Rata

[moritz]

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?

[DrHyde]

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.