Building rock solid software in  the real world Improving team workflow to improve your  software
<ul><li>Omni Adams </li></ul><ul><li>@omnicolor </li></ul>
About me
About me
About me
About me
About me
Automated checks
Code reviews
Submitting your code
<ul><li>$ cd /pub </li></ul><ul><li>$ more beer </li></ul>Code gets built You get tanked After code is submitted
Automatic checks
Automated checks <ul><ul><li>Lint </li></ul></ul><ul><ul><li>PHPUnit </li></ul></ul><ul><ul><li>PHP_CodeSniffer </li></ul>...
Automatic checks Lint...
Automatic checks PHPUnit
Automatic checks PHPCode_Sniffer
Automatic checks 
Automatic checks PHPCPD
Automatic checks PHPDCD
Automatic checks Code Coverage
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
<ul><li>Things the tools can't catch: </li></ul><ul><ul><li>Logic errors </li></ul></ul><ul><ul><li>Off-by-one errors </li...
Style guides
Style guides
Style guides <ul><ul><li>Make your own </li></ul></ul><ul><ul><li>Use existing </li></ul></ul>
Style guides
Style guides
Style guides <?php or <? or <% $variableName or $variable_name ClassName or Class_Name Line length Ternary operator Docume...
Submitting code
After submitting
After submitting
After submitting
Upcoming SlideShare
Loading in …5

Building rock solid software in the real world


Published on

Though I doubt they'll be that useful without the talk (, here's my slides.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Title screen
  • About me follow on twitter --&gt;I work at
  • I work at Ning (reveal) 1. acquired by Glam. 2. sorry 3. Glam Media --&gt;I write code
  • I write code mainly PHP and javascript --&gt; I play
  • hockey --&gt; I have
  • wife, kid, cat --&gt; I drink
  • beer, especially when there are clouds around. Enough about me --&gt; this talk is about
  • how to build better software as a team * not perfect * can be better * improve process to improve software --&gt;here&apos;s a typical
  • software lifecycle: * Plan * Code * Run automated checks * Get a peer review * Submit your code * While your CI server builds it, you get beer --&gt;This talk is not
  • about planning --&gt; nor is it about
  • coding * sure you&apos;re great coders * don&apos;t need any help * never make mistakes but I bet your team members do --&gt; We&apos;ll talk a bit about
  • automated checks to QA code before it gets submitted. --&gt; Quite a bit about 
  • code reviews, your chance to head off facepalm worthy code before it causes damage. --&gt; We&apos;ll talk some about
  • submitting code and possibly blocking bad code there. --&gt; And finally a bit about
  • what happens after code gets submitted.
  • First up: automated checks some things are easy to catch. You need HAL 9000... (reveal X3) * sorry dave * I can&apos;t let * you do that most of these can also run in your CB
  • Here&apos;s an alphabet soup of checks you can run. We&apos;ll go through these individually. All help coders fix mistakes before they submit them. (reveal X3) * computer * says * no --&gt; the first tool is
  • lint * bare minimum * finds syntax errors * many things that might cause a fatal error --&gt; a more rigorous tool for catching problems is
  • phpunit * defacto standard for unit testing, or you can use simple test * too many other talks on PHPUnit, so I&apos;ll gloss over * those two should be run in pre-commit and in the CI server * the following should be available to run before commit * and run always as part of CI --&gt; The first tool is PHP code sniffer
  • code sniffer * statically analyzes code for &amp;quot;smells&amp;quot; or bad things * missing docblocks * bad indentation * braces in the wrong place * most things in your style guide can be coded as a smell --&gt; next is PHPMD
  • the mess detector Finds: * too long methods * bad language constructs (eval, goto) * unused variables * excessive complexity --&gt; the PHPCPD or
  • copy paste detector * finds code blocks that are similar * should be refactored so the common code is in one place * keeps from having to remember --&gt; the there&apos;s the PHPDCD
  • or dead code detector * find unreachable or uncalled code * code after return * code after exit * code in a conditional never fires --&gt; finally, there&apos;s
  • code coverage * not really an automated check * you may want to run as part of the pre-flight check * shouldn&apos;t block submission --&gt; moving on to code reviews
  • which are your chance to say DOIN IT RONG * used two code review packages * free as in speech and beer -&gt; the first is
  • review board * written in Python and Django pros: * You host on your server * code never leaves your network cons: * you host on your server --&gt; the second is
  • * hosted on Google AppEngine * base on Mondrian (from Google) * Written by Guido Van Rossum (python) upload to Google&apos;s servers three types of review --&gt; pre review
  • Stops bad code --&gt; or post review
  • bad things have already happened You can guess which I prefer --&gt; there is also
  • a team review with a projector has problems * can embarrass the coder * can split the team * build groupthink --&gt; what you&apos;re looking for
  • anything the tools couldn&apos;t catch * logic errors (like ifs that don&apos;t make sense) * loops with off-by-one * performance problems (SQL in a loop) * things to refactor (large methods) or things they missed: * Style problems (not really wrong, but you know, wrong) * Typos (variable names, documentation) * Tests that don&apos;t have assertions * Methods without tests Again, your chance to say (reveal X4) YORE DOIN IT RONG --&gt; To really do code reviews right, you need a good 
  • Some people don&apos;t have style --&gt; some do
  • -- so how do we create a style
  • two options: * roll your own * use an existing
  • build your own * look at your code * build guide off that Pros: * don&apos;t have to change your code Cons: * More changes to code sniffer to use it, if you even can * New developers will argue against it * can be difficult to agree on styles --&gt;or you can
  • use an existing guide Like pear or zend Pros: * well established * smart people made them * code sniffer may already have sniffs * very explicit Cons: * Your team probably won&apos;t agree * your existing code probably doesn&apos;t already follow guide --&gt; what to include
  • in your style guide * what kind of php tags to allow * variable and class names * line length * forbidden code * how documentation is created --&gt; Moving on to submitting code
  • * Run automated checks again * Good time to run even more checks (slow tests) Use repository hooks * Unit tests pass * Submitted code has a review Last chance to keep bad code out -- Code then goes to
  • continuous build which * builds documentation * runs unit tests * calculates code coverage * builds reports * sends emails * updates dashboards --&gt;breaking the build
  • should have consequences * can&apos;t leave until it&apos;s fixed * become the build master until next break --&gt; another helpful thing is
  • to make it visible build orbs
  • Questions?
  • Building rock solid software in the real world

    1. 1. Building rock solid software in the real world Improving team workflow to improve your  software
    2. 2. <ul><li>Omni Adams </li></ul><ul><li>@omnicolor </li></ul>
    3. 3. About me
    4. 4. About me
    5. 5. About me
    6. 6. About me
    7. 7. About me
    8. 8.
    9. 10. Planning
    10. 11. Coding
    11. 12. Automated checks
    12. 13. Code reviews
    13. 14. Submitting your code
    14. 15. <ul><li>$ cd /pub </li></ul><ul><li>$ more beer </li></ul>Code gets built You get tanked After code is submitted
    15. 16. Automatic checks
    16. 17. Automated checks <ul><ul><li>Lint </li></ul></ul><ul><ul><li>PHPUnit </li></ul></ul><ul><ul><li>PHP_CodeSniffer </li></ul></ul><ul><ul><li>PHPMD </li></ul></ul><ul><ul><li>PHPCPD </li></ul></ul><ul><ul><li>PHPDCD </li></ul></ul><ul><ul><li>Code coverage </li></ul></ul>
    17. 18. Automatic checks Lint php -l
    18. 19. Automatic checks PHPUnit
    19. 20. Automatic checks PHPCode_Sniffer
    20. 21. Automatic checks 
    21. 22. Automatic checks PHPCPD
    22. 23. Automatic checks PHPDCD
    23. 24. Automatic checks Code Coverage
    24. 25. Code reviews
    25. 26. Code reviews
    26. 27. Code reviews
    27. 28. Code reviews
    28. 29. Code reviews
    29. 30. Code reviews
    30. 31. <ul><li>Things the tools can't catch: </li></ul><ul><ul><li>Logic errors </li></ul></ul><ul><ul><li>Off-by-one errors </li></ul></ul><ul><ul><li>Obvious performance problems </li></ul></ul><ul><ul><li>Refactoring opportunities </li></ul></ul><ul><ul><li>Bad/misleading documentation </li></ul></ul><ul><li>Things the tools missed: </li></ul><ul><ul><li>Style problems </li></ul></ul><ul><ul><li>Syntax errors </li></ul></ul><ul><ul><li>Typos </li></ul></ul><ul><ul><li>Unreachable code </li></ul></ul><ul><ul><li>Useless tests </li></ul></ul><ul><ul><li>Missing tests </li></ul></ul>Code reviews
    31. 32. Style guides
    32. 33. Style guides
    33. 34. Style guides <ul><ul><li>Make your own </li></ul></ul><ul><ul><li>Use existing </li></ul></ul>
    34. 35. Style guides
    35. 36. Style guides
    36. 37. Style guides <?php or <? or <% $variableName or $variable_name ClassName or Class_Name Line length Ternary operator Documentation
    37. 38. Submitting code
    38. 39. After submitting
    39. 40. After submitting
    40. 41. After submitting