Upgrade to Pro — share decks privately, control downloads, hide ads and more …

I can't believe you still do it that way: PHP best practices retrospective

I can't believe you still do it that way: PHP best practices retrospective

Slightly updated version of this deck for the SkiPHP opening keynote.

Laura Thomson

January 17, 2014

More Decks by Laura Thomson

Other Decks in Technology


  1. Laura Thomson @lxt I can’t believe you still do it

    that way: a best practices retrospective 1
  2. Format §Disclaimer: Anything with a black header is a vintage

    slide and may be dated §Reading your own old slides is like reading old code :( §Each topic through the ages 2001-2014 3
  3. Your PHP should •be simple •get the job done •be

    secure •be scalable and performant •be producible and maintainable Principles 6
  4. • PHP frameworks are proliferating, and Rails doesn’t help. •

    Having an architecture like MVC can be a really good thing, but: • Everybody has a different idea about how this ought to be implemented • Some of the ideas are really twisted • Some make it hard to do very basic things simply • Code bloat • Which framework? • No dominant paradigm yet, ergo little help with maintainability Have  a  clear,  simple,  architecture  that  is  easy  to  add  to,  easy  to  explain  to  new  developers,  and  easy   to  remember  now  or  in  two  or  five  years’  *me. Frameworks  and  Architectures:  use  and  abuse 15
  5. Framework best practices §Lightweight beats heavyweight (unless it doesn’t) §CRUD,

    junior devs, MVP, giant teams §ORM is a kickstarter: training wheels for your app §Use what works, and throw it away when it doesn’t 20
  6. 2014 §Minimize and isolate failure effects §Self-healing systems §Resilience: as

    much of it should work as possible §Feature flagging: turn off parts of your app that are broken or under load 31
  7. • Consider illegitimate uses of your application • Educate yourself

    • If nothing else, filter all external data –(From the PHP Security Guide at http://phpsec.org/ projects/guide/) Basic  principles 33
  8. • External data is not to be trusted. • What’s

    external data? • Anything from a form • Anything from $_GET, $_POST, $_REQUEST • Cookies • Some server variables (e.g. $_SERVER['SERVER_NAME']) • Database query results • Web services data • Files • The basic principle is to filter input and escape output • Filter input using whitelisting where possible • Escape output according to where it’s going. External  Data 34
  9. • Some common problems: • register_globals issues • XSS (Cross

    Site Scripting) • SQL/Command Injection • Code injection • Other things to worry about: • Exposed source code • Session fixation • Session hijacking • Cross site request forgeries (CSRF) •Cross domain Ajax requests AGacks 35
  10. 2001 §Use SSL §Don't store credit card numbers §Escape output

    naively (we didn’t know we were naive, honest) §addslashes()/stripslashes() 38
  11. • Profile early, profile often. • Dev-ops cooperation is essential.

    • Test on production data. • Track and trend. • Assumptions will burn you. General  Best  Prac*ces 43
  12. •Use a compiler cache. •Be mindful of using external data

    sources. •Avoid recursive or heavy looping code. •Don’t try to outsmart PHP. •Build with caching in mind. Performance 45
  13. 2007 §Stand back, I’m going to use science §Measure, track,

    trend, profile, optimize §Build cachable code §Decouple reads from writes (write there, read here) §Replicate, federate 49
  14. •Above all, code needs to be readable and maintainable •Beware

    clever code: –cool design patterns –obscure performance tweaks –niche language features Write  good  code 52
  15. •Turn error_reporting up in dev and display_errors off in production

    •Use set_error_handler() and set_exception_handler() for top level errors •Whacking all your code in a try…catch block is not a panacea. Errors  and  Excep*ons 53
  16. •Have and use a coding standard •Zend Framework, PEAR, homebrew

    •Legacy code always a problem Coding  standards 54
  17. 2008 §Make it look as much like Java as possible.

    §Namespaces §Iterators 58
  18. 2014 §So many nice nice things §PHP 5.4 generators and

    anonymous functions and traits, oh my §(It’s beginning to look a lot like Christmas Ruby) §I’m kidding. Kind of. §Composer! PHPUnit! PHPDoc! Doctrine! 59
  19. • The process needs managing • Use a version control

    system • Have a testing and release process • Have an easy way for developers to set up a staging server • Plan for scale                Web  Dev  is  SoMware  Dev 61
  20. 2014 §Better tools for everything §Continuous integration and deployment §Test

    automation and monitoring converge §Commoditization of version control §MTTR vs MTBF 66
  21. PHP is not a best practice §PHP is an anti-pattern

    §Pinnacle of bad design §All PHP developers are incompetent §PHP is only suitable for making trivial personal sites 68
  22. 2014 PHP is for losers. You should use... §Python §Ruby

    §Node §Scala §Clojure §Erlang 72
  23. 73