Page 1 of 1

Joining a team, where no wiki or docs are available

Posted: Mon Sep 24, 2012 9:14 am
by Behzad
Hi,

i'm going to join a mid-size company with a few PHP-driven projects
written in procedural PHP, million years old.

At the moment, they don't have a wiki or any documentation about their
projects. For me, the first challenge in probation period is to understand
how their code works.

Considering that there is no wiki or docs, How can I see the Big Picture?
i'm sure this is a common problem for programmers everywhere.

What approach do you use in a similar situation?
Is there a systematic approach for this?
Is there reverse-engineering technique to understand the design of code?

Please share your experience and thoughts.

-Thanks in advance,
Behzad

P.S. I'm not sure whether this is related to "Theory and Design" or "Enterprise".
I posted this in this section, since the aim is to understand the *design*

Re: Joining a team, where no wiki or docs are available

Posted: Mon Sep 24, 2012 10:52 am
by Christopher
You might want to start by writing some tests -- especially for an area of the code for which there are reported problems. Fixing problem areas will give you credibility. Writing tests will 1) reveal the problem, 2) document what the code is supposed to do, and 3) support refactoring the code later to better designed code.

Re: Joining a team, where no wiki or docs are available

Posted: Fri Jan 25, 2013 11:57 am
by thinsoldier
When you say "procedural" do you mean they don't even have their own developer-created functions? If they do have their own functions write tests against and utilizing those functions. If they don't then you'll be sort of simultaneously refactoring their code while you copy/paste their un-functioned code into functions you can test. Once you've got sensible functions set up and tests that pass you might be able to talk them into doing a real refactoring.

But if your main need is to see how things work and tie together I suggest setting up a copy of their projects on your personal system with xdebug installed and run them and step through the execution with a debugger. Try to make useful notes about the code while you do this. The last time I did this I had a lot of notes like:

[a] foo.php lines 36 to 80 is almost identical to bar.php lines 120 to 170
[-] bingo.php lines 50 to 100 match [a]
[-] dingo.php lines 150 to 200 match [a]
foo.php lines 100 to 110 has the same logical structure as [a] but shorter (less string manipulation, less security checks). Consider making a base class out of [a] and have either extend on consume [a]

Having a copy of the projects on your own machine makes it easier for you to add your own comments to the code to help you out while stepping through the debugger.