Search


Categories

PHP/MySQL Best Practices

Laura Thomson came all the way from Australia to present the last talk I went to at ApacheCon – PHP/MySQL Best Practices – and for me at least, it was well worth her trouble. This was originally submitted as a tutorial, and was only converted to a talk at the last minute, so we were really lucky to have her!

Talk-lite – 45 mins instead of 3hrs

Design DBs & apps without big holes
Maintainance

Clear vision for architecture = good
‘Framework’ = trendy buzzword

Everyone has a different idea
Some frameworks lead to bloat, and make it hard to do simple things simple

No paradigm for frameworks = no help with maintainability, transferable code
skills

Have a clear & simple architecture
Easy to add to
Easy to explain to new people
Easy to remember now, and in 2/5/10 years

Database extraction = MYTH!!!
Changing PHP = easy
DB chosen based on features
DB extraction layers inefficient/slow/cumbersome

Data access extraction – PDO
Standardise on prepared statements – MySQL4.1

Templating languages (database extraction & frameworks also) – religious issue

Start simple, can’t help but adding features
Ends up with feature-complete languages, adds a layer of complexity = layer of
inefficiencies, something else to break

ARCHITECT FOR YOURSELF – presume that /you/ will be maintaining this in the
future

Don’t rely on server config – write the most portable code possible (security,
ini settings)

Design with security from the ground up – dispatch architecture = single line of
execution

CODE REVIEW – code quality++, make sure code is developed sensibly

Security audit – particularly with inherited/legacy code

Education, education, education – make it easy to do the right thing

Use error reporting – turn it right up on development servers
Aim to write code that doesn’t throw any notices
Turn error level down, or display_errors off, on production servers – attackers
can use error messages to make better attacks

Education – developers don’t know better
Code review from peer-to-peer, formal code review, mentor junior staff, read
commits
Developer education is a good addition to any security audit

Integrating against external data sources – don’t trust them
Don’t trust them to stay the same, be secure (injection attacks), be there at al
l!

Layer of abstraction++
Web2.0/AJAX/DHTML – JS heavy
Nightmare to debug and maintain

Firebug = God’s gift to JS programmers


Maintainability

Can someone understand your code, change & update it? Can /you/? Can the code be
extended/adapted?
“It’s just a hack” – turns into 10,000 lines of code, go back and look at first
500 – they’re buggy, hellish, breakable

THINK AHEAD

Developer ignorance is a big problem

For small project – write small code, be prepared to throw it away if it turns
into a big project
For big project, DESIGN FIRST

Problems arise when projects grow organically

Self-taught/junior developers aren’t the only ignorant developers
Lack of experience with teams/inability to adapt & be flexible
Lack of experience with developing significant (100,000 LOC) codebases
Lack of experience with someone else’s awful code! – #1 driver for developers to
improve is having to maintain someone else’s code!

Obfuscated code – crossword puzzle anyone?
Poor naming conventions – Hungarian notation = most abused naming on the planet
Abuse of define()
Seventeen layers of handoff
Reimplementation of built-ins/standard library functions – esp array functions
Failure to do /the simplest thing that could possibly work/
Premature optimisation – and it’s practically always premature! Obfuscates code,
usually without a good reason

Failure to comment /appropriately/ – “set foo to true if this is true” +
insanely complicated formula
Inline functions–
Nasty side effects – eg library file that includes executable code
Failure to read & fit in with existing code – use functions already in the code
where they exist

Not just about meeting a coding standard – it’s about THINKING!!!
That said – have and use a coding standard
No need to make from scratch – PEAR & Zend Framework have them. Good place to
start anyway
Use a coding standard from the start – nightmares happen if you try to do it
later!

Make rules awkward/hard to remember = no one will use them
Force millions of tiny files = performance hit
Apps Hungarian = just no
If you want something totally OO, use Java or Python
Formatting – use long form PHP tags
Space indents, or tabs, but everyone should use the same!
Comments – header block!
Single line comments for non-obvious code, TODOs, FIXMEs etc
Coding semantics – declare functions/classes in library files that don’t have
execution side effects
Code should run clean with E_ALL
Don’t use magic numbers, ternary operators, embedded HTML

Version control for anything that’ll take more than one week, one code file or
one developer – and most of those too!
Frequent commits – every conceptual change, additional functionality, every bug
fix should have a commit
Detailed commit messages – trac is a PITA, but trac++ still

DOCUMENTATION – any project beyond a certain size needs it. Organic code–
If you don’t document as you go, you never will
Aim for consistently produced lightweight docs – takes less time (so it just
might happen), and is quicker to read

TRAIN DEVELOPERS – code layout/design, sample code, explainations of
architecture/requirements – FEEDBACK

Hell is other people’s code – legacy code: the ninth circle of hell
You may never read all the legacy code
Parts of it are broken, were never used
If it wasn’t documented before, you never will
If it needs a complete rewrite, you won’t have time
You will have to deal with this. If not today, sometime soon.

Worth spending time to audit documentation, architecture, coding conventions,
what’s used, what’s obviously broken/fragile
Refactor as you go, with a lightweight plan in mind
Don’t get too ambitious

3 comments to PHP/MySQL Best Practices

  • “If you pick the right people and give them the opportunity to spread their wings—and put compensation as a carrier behind it—you almost don’t have to manage them.”
    — Jack Welch

  • Did sound an interesting talk – I wish I’d been to it about 6 years ago :-)

    Some thoughts:

    Firstly, as far as I can tell, there is beginning to be some consensus on frameworks. As far as I can tell, the MVC model is becoming the de-facto standard. People are beginning to get used to PEAR (at last). Seagull [http://seagullproject.org/] is a good example of both. You also need to be careful with licensing issues: not everyone wants to GPL! Seagull is BSD.

    I agree that DB abstraction is largely a myth and can add a lot of overhead (PEAR::DB for one – I often still use PHPLIB’s ancient (low level) DB class. Realistically, most PHP projects are only ever going to use MySQL or PostGres, and so long as you keep the DB queries in some sort of layer of DB access classes, there is no need to use some high-level over-generic solution.

    Most important thought last: learn PHPDOC [http://www.phpdoc.org/] and use it all the time. Many PHP develpment environments understand PHPDOC headers so you get an immediate reward, and it’s pretty simple to generate uptodate API documentation whenever it’s needed.

  • that sounds like it was a very interesting talk.

    Noirin, you wouldn’t happen to have a link for slides or more details? a podcast would be bloody fantastic.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>