onekay

Today I am at the PHP Conference London 2008, with about 300 other developers. We’ve all listened to Ivo Jansch in his “PHP Enterprise” talk, which is a good discussion of software engineering for php developers.

I’m currently listening to Stefan Esser’s”Binary PHP Analysis” talk which is a really useful insight into php security auditing.

There have been a few blog posts floating around about a talk Tim Bray delivered at the International PHP Conference 2006. I wasn’t at the conference, nor have I heard the talk or seen slides, I’ve just read what Tobias Schlitt said about it. The other day Jeff Moore raised an interesting question - Why is PHP Code Considered Hard to Maintain?

Jeff suggests that its not PHP itself that is hard to maintain, but the programs that make it so popular, wordpress, phpMyAdmin, phpBB… those sort of things, and to a certian extent I agree. Some of the most popular php programs are a mess, and would be hard to maintain, PHP does make it easy to write code that is hard to maintain. Thats not to say it makes it hard to code ‘easy-to-maintain’ code, just that it can be easy to write sloppy PHP.

Writing maintanable code takes a degree of disipline, but it isn’t hard and it certianly has its rewards.

• Have coding standards. And stick to them. Every developer has thier own preferences, but reach a compromise with everyone on the team and agree on a set of standards that will help you keep all your code looking similar. It should be easy to scan, and will look neat. There are plenty of places to start - take a look at the PEAR standards as a starting point for your project. Dont be a nazi about your coding standards though concentrate on keeping code readable rather than strictly adhering to the standards doc.
• Organize your files. Firstly keep anything that isn’t supposed to be reached through a URL out of the webroot - templates, include files, configs, class files, log files, backups, cron scripts etc. This stuff shouldn’t be browsable. You can hide it in folders with ‘Deny from all’ directives in a .htaccess file - but its better to sit it below the webroot.Then look at your web visible file structure - put images in img/, stylesheets in styles/ and so on. Once your web visible structure is in order, then think about what you have below your webroot.Your filename conventions are also important. I normally start each class with a capital letter - so files like Template.php and Model_Abstract.class are classes, anything else is normally lowercase, underscore separated and with an extra extension if they are included files: main_header.tpl.php, global.inc.php, default_style.css default_style_print.css
• Separate your presentation logic from your page logic. Everyone says do this, but no one really explains _why_ you should do it. Separating these things allows you to re-use your presentation code elsewhere. It means your designers can play with the design _without_ ever breaking the application behind it. Remember that separation of code isn’t the same as separation of logic, for instance, alternating table row colours is presentation logic, and should be done in that layer, while checking users are logged in and have access to the specific page is page logic, and shouldn’t be done in the display layer. Savant is an excellent place to start.

• Use less code. This is obvious - the less code you write, the less you have to maintain. Re-use code wherever you can, and dont write anything you dont need. Refactor code as you go to make it as streamlined as possible. Remember to remove redundant code too.

• Documentation. Documentation. Documentation. These have got to be the three most important things to remember when it comes to maintainable code. Document your code as you write it - explain what everything does and why you’re doing it that way. This will help when you, or someone else comes to revisit the code in six months time and has to work out what it does. As a rule of thumb document anything that you can’t understand with a quick glance.You should try and comment all variable declarations, especially if the name doesn’t describe the variable too well.Each file should contain a file level docblock describing the use of the file, If a script takes _GET parameters or ARGV arguments (command line) a docblock containing a usage example should be written in the file level docblock. A usage example should be given for any classes that are not normally initiated using the constructor (eg factory classes)

  Comment on numeric data, if a number represents a length or distance, comment what units it is in (meters, miles, hours etc.)
  Comments should be used to identify missing functionality or unresolved (known) issues in the code. PHPDoc has a @todo tag specifically for this. If a block of code is commented, an explanation should be given for why it is commented, and by whom - even if it is just a temporary hack.

• Obey the OO principles you learnt at school. Encapsulate what varies, use inheritance but favour composition, depend on abstractions not concrete implementations, strive for loosly coupled objects, program to an interface not an implementation, keep classes open for extension, closed for modification yadda yadda yadda. There are enough resources online about this stuff

There you go - you have a codebase that you can come back to at any time and understand - or let a competent developer loose upon without being hugely embarrassed. \o/

At webgains we’re finally making the move from CVS to Subversion now and it seems to have a whole lot of benefits with it - cheap (time and space) branching is by far the biggest improvement - suddenly merging branches doesn’t seem like such a daunting task anymore. This move comes at a time when we’re preparing the system for internationalisation, so having a smoother version control (and with it, better deployment management) is going to be a big help.

There are a number of things you can do with your version control to make sure that your teams development and deployment goes as smoothly as possible:

Keep a stable release branch, and work on an unstable trunk
If your developers can commit to the trunk, without fear of messing up the live system, then they will be able to commit more often. If they can commit more often thier work is backed up to the repository, and the team will have to deal with less conflicts. If you have a stable build of the site/software on a branch, then you can merge the selected changes to it in order to do a release, rather than upload the bleeding edge trunk straight to the live system.

Have a staging ‘test’ area to test a release before it is put on the stable branch.
This means keeping a copy of your software or site somewhere that people dont make changes to - its not a sandbox development area, its a test environment as close as you can get to the live system where you can test and benchmark your stuff before the code goes live.

Review code before it is commited to the testing branch
Once the code is in a testing or live environment, its too late to refactor or rewrite code, so a code review isn’t all that useful here. Review _before_ it is merged to the live or testing branch, because this is the best opportunity you have before its sitting on a live website being tested for real. Dont look at code reviews as a huge formal organisational administrative thing that you’d love to have the time in your team to do - it doesn’t need to be more than another developer looking through the code, making some notes and informally talking through it with the coder.

Have a release number
It can seem strange to have release numbers for an in house website or other similar projects, where there is no distributed application, and it can be difficult to apply some of the principles of software engineering to a project like that - it tends to grow organically and features and bugs are introduced on an ad hoc basis. This isn’t always a bad thing, but the bigger your project becomes, and the more developers you have working on it - the harder it will be to manage well. Having a release or version number makes a website build/maintanance seem a bit more like a software development - and makes it easier to see how to apply software engineering principles (like version control, code reviews, unit testing and software modelling) to your project.

Obviously these all take a bit of dicipline and hard work, but thats what being a good developer is all about.