Last week I passed a day speeding up a Java and Ruby oriented team which started developing a PHP application: not only a standard project structure was required, but also some hints on the default tools and process to work with it.
Here's what I thought was crucial during the setup, based on the question of my Rubyist colleague. Of course one of the most visible differences is the language itself, but there is a lot more tacit knowledge to share.
The php interpreter can be installed for usage from the command line, and as a consequence PHPUnit can be installed via PEAR ($ pear) to provide the phpunit command.
Phing is an Ant equivalent that makes it easier to integrate PHP-based tools as task. In our case, it is not necessary for starting out as in most cases it's just an interface over shell scripts. We automatically choose Vim for the editing part, but IDEs are welcome if you have an habit of working with them.
Jenkins is the standard choice for Continuous Integration, and it's not really dependent on the language; if we need a PHP-specific static analysis tool we'll look for a template and to introduce Phing build files.
Compared with Java, PHP has many similarities: classes and interfaces as constructs, plus private, protected and public visibility for fields and methods. Due to the common age, both languages have several scalar base types like int and bool, but PHP also has string as one of them.
A similarity with Ruby is the presence of dynamic typing: you'll never see typing information on fields and parameters if not for documentation or defensive programming (like type hints).
The advantages of PHP are that it's built for the web, featuring a model based on lots of different workers each executing a PHP process. There are lots of batteries included for working with HTTP, formats and databases; and deployment is very easy.
The defects you'll live with are that these batteries are scattered in the global namespace, mostly as functions for historical reasons. But for any help, type php.net/functionname in your browser to see documentation on parameters, return values, edge cases and sample usage.
A common choice for organizing code (mostly classes, each with its own source file) is in two src/ and test/ parallel trees. Classes should follow the PSR-0 standard, placing the Acme\Rocket class into src/Acme/Rocket.php; and should really use namespace in new code instead of underscores.
Autoload is commonly set up in test/bootstrap.php (that can later be shared with index.php or other entry points), using:
- __DIR__ as a magic constant pointing to the test/ folder.
- ini_set("include_path") to modify the paths where files would be searched by require_once() (think of the Java class path).
- spl_autoload_register() to define a function or closure to load classes based on their name.
PHPUnit provides the standard xUnit API: test*() methods are executed independently, setUp() and teardown() provide space for fixtures, and assert*() methods verify expectation on the code.
PHPUnit test cases also provides a point of entry with $this->getMock() to generate any kind of Test Double from a class or interface name. There is no need for verify calls: mock expectations are defined before their usage and checked automatically by the framework when appropriate.
phpunit.xml is a configuration file which I advise to setup to enable colors, bootstrap.php to be automatically used and to define the folder containing the test suite.
phpunit executed where phpunit.xml resides will run all the tests. You can also make a selection:
- phpunit --filter testMethodName executes only testMethodName() methods (also with an incomplete name).
- phpunit --group groupName allows you to filter test cases and methods tagged with @group.
- phpunit test/Acme/Rocket/ only executes a subset of tests, contained in the chosen folder.
Many libraries for common problems like working with HTTP, SQL, JSON and XML are included in the language: json_encode(), SimpleXML, PDO and the Mongo extension.
Frameworks were not needed for now, but Zend Framework and Symfony are the first places to look if you're not afraid of technical debt.
ORMs are also a commodity, and in case you need to deal with many different entities the Doctrine ORM is my first choice. Also Doctrine ODMs are available for mapping objects into document databases such as CouchDB and MongoDB.