> -----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 http://trac.edgewall.org/ 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). http://subversion.apache.org/ 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. http://www.mysql.com/products/workbench/ 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. http://www.zend.com/en/products/studio/ 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. http://xdebug.org/ 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. d -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
