> -----Original Message-----
> From: AmirBehzad Eslami [mailto:behzad.esl...@gmail.com]
> Sent: Monday, September 24, 2012 7:05 AM
> To: PHP General Mailing List
> Subject: [PHP] Joining a team, where no wiki or docs are available
> 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

I was in this same situation when I started 2011-03. No wiki. No revision 
control. No real process. No documentation. They'd push to production by 
copying files manually. When they wanted to create a new website, they'd clone 
an existing one and start modifying -- no shared libraries (so they had 50 
versions of the same dbconnection.class.php but all just slightly different 
since that is also where they housed the configuration user/pass/etc.)!! It was 
a clu$terfsck.

Take a day or two to go through every menu item and just see how the thing 
works from a user POV. You don't have to memorize it, just be familiar with 
concepts, vocabulary, paths, etc.

First thing I did was install Trac

And of course Subversion. I personally recommend the 1.6 branch and not the 
newer 1.7 that uses sqlite. That version seems to always corrupt, especially on 
the clients (like in TortoiseSVN).

I would use something to visually map out the database. If it's using MySQL, 
there are free tools like MySQL Workbench. But if they don't use InnoDB tables, 
it can get painful to draw the lines if it's a large DB.

I then started to go through code and use PHPDoc for every major function or 
method, especially in classes or include files where the meaty stuff happens, 
or very complex portions. I didn't bother with every get_* or set_* unless 
there was something obscure about them. Although, over a year later, and we 
have pretty much filled them all in now as the other devs started helping once 
they saw how easy it is to do a few as you encounter them in your daily coding, 
and how awesome that integrates with PDT or Zend Studio (amongst other IDEs). 
We didn't generate an actual PHPDoc Web version, there's really no need. The 
IDE shows you the important stuff anyways. We're pretty diligent about keeping 
these PHPDoc comment blocks updated now.

I then started the long tedious process of merging our various different sites 
to implement shared libraries (database connections, memecache, various 
objects, etc.). If you have only one project, then this is less of an issue, 
but if you have > 1 vhost or something then you'll want to do this.

All the while I documented useful tips, tricks, explanations, etc. in the Wiki. 
Referencing source code (which is of course committed at this point). Trac 
rules in that respect.

Xdebug will give you vastly better call stack and var_dump() alone. I don't use 
the breakpoint stuff myself, but that is another benefit perhaps.

And for the love of [insert deity of your choice here] not EVERYTHING has to be 
OOP. Use the best tool for the job!! Nothing pisses me off more than having to 
instantiate a new class just to do some simple method that a standard function 
would do. If you want to be organized, use static methods then where 
appropriate, but don't avoid functions just because some book told you that OOP 
is the king $hit.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to