Fri, 30 Jun 2006

ApacheCon '06 : PHP and MySQL Best Practices

Laura Thomson (OmniTI) presented "More of a rant and less of a technical talk" - it being Friday evening :-)

Firstly, frameworks - they're largely buzzwords and since there's no dominant paradigm, so they tend not to be a huge help with maintainability. Having a clear, simple architecture that's easy to add to, easy to explain to new developers and easy to remember now and in two or five years time is best.

Be careful of the dubious merits of DB abstraction layers. They can be slow and cumbersome - and changing the PHP code to change database is most likely not going to be the most difficult part of the migration. Do use PDO, which is a standard for data access abstraction and standardise on the use of prepared statements.

Design for security

Don't rely on server configuration to protect you - particularly for applications that will be distributed.
Design for security from the ground up.
Code reviews are a good thing.
Seek advice from experts.
Educate yourself and others and where possible make it easy for your staff to do the right thing.
Keep your installation up to date. Make sure patches are applied in a timely fashion and read advisories.

Turn errors up during the development phase and read the error logs. Either turn the error reporting down (or off) on a production machine, or set display errors to no.

If integrating with an external API, you cannot trust that:

it will stay the same.
it will be secure.
it will be up and available.

You should probably wrap this up in an object to insulate you against API changes and with added checking to allow extra checking for security purposes.

The acid test:

Can someone else understand your code enough to change it?
Can you undertstand your code enough to change it?
Can the code be extended and adapted?

maintainability problems often occur where a project is assumed to be a quick, small project - but then grows into a large project without the checks and balances and structures having been put in place.

Think about: common errors, coding standards and version control. Lots of work has already been done and is available for you in books and on the web. Coding standards exist for PEAR and for the Zend Framework - use these either directly or as a base from which to create your own.

posted at: 17:53 | path: /technical | permanent link to this entry