Building rock solid software in the real world
•Télécharger en tant que PPT, PDF•
0 j'aime•388 vues
Though I doubt they'll be that useful without the talk (http://www.ustream.tv/recorded/18398170), here's my slides.
![[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Building rock solid software in the real world
Similaire à Building rock solid software in the real world (20)
Dernier
Dernier (20)
Building rock solid software in the real world
- 1. Building rock solid software in the real world Improving team workflow to improve your software http://www.flickr.com/photos/preef/32995286/
- 3. About me
- 4. About me
- 5. About me
- 6. About me
- 7. About me
- 10. Planning
- 13. Code reviews
- 16. Automatic checks
- 18. Automatic checks http://www.inquisitr.com/88424/a-hint-you-might-really-need-to-find-a-life-collect-bellybutton-lint/ Lint php -l
- 21. Automatic checks http://itsnotenoughitstoomuch.blogspot.com/2011/02/real-mess.html http://phpmd.org/
- 24. Automatic checks Code Coverage
- 28. Code reviews
- 29. Code reviews
- 30. Code reviews
- 33. Style guides
- 35. Style guides
- 36. Style guides
- 37. Style guides <?php or <? or <% $variableName or $variable_name ClassName or Class_Name Line length Ternary operator Documentation
- 38. Submitting code
- 39. After submitting
- 40. After submitting
- 41. After submitting
Notes de l'éditeur
- Title screen
- About me follow on twitter -->I work at
- I work at Ning (reveal) 1. acquired by Glam. 2. sorry 3. Glam Media -->I write code
- I write code mainly PHP and javascript --> I play
- hockey --> I have
- wife, kid, cat --> I drink
- beer, especially when there are clouds around. Enough about me --> this talk is about
- how to build better software as a team * not perfect * can be better * improve process to improve software -->here'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 -->This talk is not
- about planning --> nor is it about
- coding * sure you're great coders * don't need any help * never make mistakes but I bet your team members do --> We'll talk a bit about
- automated checks to QA code before it gets submitted. --> Quite a bit about
- code reviews, your chance to head off facepalm worthy code before it causes damage. --> We'll talk some about
- submitting code and possibly blocking bad code there. --> 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't let * you do that most of these can also run in your CB
- Here's an alphabet soup of checks you can run. We'll go through these individually. All help coders fix mistakes before they submit them. (reveal X3) * computer * says * no --> the first tool is
- lint * bare minimum * finds syntax errors * many things that might cause a fatal error --> 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'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 --> The first tool is PHP code sniffer
- code sniffer * statically analyzes code for &quot;smells&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 --> next is PHPMD
- the mess detector Finds: * too long methods * bad language constructs (eval, goto) * unused variables * excessive complexity --> 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 --> the there's the PHPDCD
- or dead code detector * find unreachable or uncalled code * code after return * code after exit * code in a conditional never fires --> finally, there's
- code coverage * not really an automated check * you may want to run as part of the pre-flight check * shouldn't block submission --> 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 -> 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 --> the second is
- codereview.appspot.com * hosted on Google AppEngine * base on Mondrian (from Google) * Written by Guido Van Rossum (python) upload to Google's servers three types of review --> pre review
- Stops bad code --> or post review
- bad things have already happened You can guess which I prefer --> there is also
- a team review with a projector has problems * can embarrass the coder * can split the team * build groupthink --> what you're looking for
- anything the tools couldn't catch * logic errors (like ifs that don'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't have assertions * Methods without tests Again, your chance to say (reveal X4) YORE DOIN IT RONG --> To really do code reviews right, you need a good
- Some people don't have style --> 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'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 -->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't agree * your existing code probably doesn't already follow guide --> 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 --> 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 -->breaking the build
- should have consequences * can't leave until it's fixed * become the build master until next break --> another helpful thing is
- to make it visible build orbs
- Questions?