Save 37% off PRO during our Black Friday Sale! »

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.

Fead61362ab9263d8cc3af52bd74168e?s=128

Laura Thomson

January 17, 2014
Tweet

Transcript

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

    that way: a best practices retrospective 1
  2. Overview §What’s a best practice? §Architecture §Security §Scalability and performance

    §Development practices §Is PHP dead? 2
  3. 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
  4. Best Practices 4

  5. §Best is a strong word §YMMV §“Good practices” Best  Prac*ces

    5
  6. Your PHP should •be simple •get the job done •be

    secure •be scalable and performant •be producible and maintainable Principles 6
  7. Architecture 7

  8. •First, do the simplest thing that could possibly work. Rule

     #1 8
  9. Text Separation of concerns 9

  10. 2001 §Put reused templates in an include file §Avoid mixing

    php and html 10
  11. 2004 §Why are you still putting php in your html?

    11
  12. 2008 §Why are you still putting php in your html?

    12
  13. 2014 §I think we’re learning. §(At least, I hope so)

    13
  14. Frameworks 14

  15. • 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
  16. 2001 §What's a framework? 16

  17. 2004 §All frameworks suck 17

  18. 2007 §They still suck, mostly §Framework shaming starting to decline

    18
  19. 2014 §PHP 5.4+ frameworks suck a lot less 19

  20. 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
  21. More than the sum 21

  22. Decomposition and decoupling #1 part of a good architecture 22

  23. 2001 §Functions §Include files 23

  24. 2004 §Objects 24

  25. 2007 §Reusable libraries §Services: everything’s an API 25

  26. 2014 §More libraries and components §More APIs §Better package/dependency injection

    tools 26
  27. Robustness and Resilience 27

  28. 2001 §Write tests. 28

  29. 2004 §TDD §Use caching (disk, memcache) to hide service failures

    §Defensive coding 29
  30. 2007 §High Availability §Failover §Multimaster (sucks) 30

  31. 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
  32. Security 32

  33. • 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
  34. • 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
  35. • 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
  36. What’s different? §register_globals and magic_quotes are dead. §Slides got less

    wordy. §Surprisingly little else. 36
  37. Web app security 37

  38. 2001 §Use SSL §Don't store credit card numbers §Escape output

    naively (we didn’t know we were naive, honest) §addslashes()/stripslashes() 38
  39. 2004 §Filter input §Escape output. §Avoid XSS/injections §mysql_real_escape_string() 39

  40. 2008 §CSRF protection §Parameterized queries/prepared statements §ORM 40

  41. 2014 §Wider use of frameworks protects devs from mistakes §New

    developers learning the right way first 41
  42. Scalability & Performance 42

  43. • 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
  44. •Decouple. •Cache. •Federate. •Replicate. •Avoid straining hard-to-scale resources. •Dev environment

    needs replication too. Scalability Best Practices 44
  45. •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
  46. Principles 46

  47. 2001 §Don’t use CGI §Tune your queries 47

  48. 2004 §Cache everything §Query cache §Disk cache §memcached 48

  49. 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
  50. 2014 §Refinement §Graph everything §Message queues to decouple writes §NoSQL/SQL:

    right data store for the job §DevOps 50
  51. Coding Practices 51

  52. •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
  53. •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
  54. •Have and use a coding standard •Zend Framework, PEAR, homebrew

    •Legacy code always a problem Coding  standards 54
  55. Code through the ages 55

  56. 2001 §Write comments. §Make code reusable. 56

  57. 2004 §Have a coding standard. §Use OO! 57

  58. 2008 §Make it look as much like Java as possible.

    §Namespaces §Iterators 58
  59. 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
  60. Process 60

  61. • 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
  62. Process through the ages 62

  63. 2001 §Test code on your own machine §FTP to production

    63
  64. 2004 §Staging server §Deploy with ‘svn up’! 64

  65. 2007 §Actual TDD §Instrumentable code! §Repeatable process §Agile §Death of

    estimation 65
  66. 2014 §Better tools for everything §Continuous integration and deployment §Test

    automation and monitoring converge §Commoditization of version control §MTTR vs MTBF 66
  67. PHP is Dead?! 67

  68. 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
  69. PHP is a toy language. You should use... §Perl §Cold

    Fusion §ASP 2001 69
  70. PHP is no good for enterprise. You should use... §ASP.NET

    §JSP §J-everything 2004 70
  71. PHP doesn’t have a single awesome framework. You should use...

    §Ruby on Rails 2007 71
  72. 2014 PHP is for losers. You should use... §Python §Ruby

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

  74. PHP coders... gonna code 74

  75. Questions? Laura Thomson laura@mozilla.com @lxt 75