Measuring Your Code

2,767 views
2,650 views

Published on

Examines some of the fundamental problems with the way the industry thinks about software "engineering", and breaks some notions in order to find useful ways of improving your code quality, and your skills and discipline as a developer.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,767
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
34
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Measuring Your Code

  1. 1. Measuring your code A talk by Nate Abele @nateabele nate.abele@gmail.com
  2. 2. Confession
  3. 3. Coercion, red bars & broken windows
  4. 4. Continuous
  5. 5. Goal: Perfection
  6. 6. Or at the least, continuous improvement
  7. 7. a.k.a. (kaizen)
  8. 8. What people usually think Estimating costs Projecting deadlines Managerial BS!
  9. 9. Client Spec Sheet some paraphrased) (actual bullet points, Flash intro with no load time User account logins, password optional Ajax chat “Like Google”
  10. 10. ...and my personal favorite Social network
  11. 11. Measurement is an essential element of management; there is little chance of controlling what we can not measure. - Wikipedia, “Software metric”
  12. 12. Wherefore... (WTF) ?
  13. 13. “Engineer” & “architect”
  14. 14. Cognitive Dissonance * Engineers deal with tangible, immutable constraints, like gravity The practice of developing software is an inherently creative discipline * Thank you, Jones
  15. 15. Cognitive Dissonance Developer constraints (scope, schedule, budget) potentially / often in flux Software is inter-related; working on one part changes the others No project is exactly the same as another
  16. 16. Conclusion It’s not useful to measure high-level, intangible things like whole projects This is where scrum comes in handy Instead, we can use lower-level, more concrete measurements
  17. 17. What can we measure?
  18. 18. Code!!
  19. 19. More specifically... Unit test coverage Complexity Speed Documentation
  20. 20. More specifically... Standards conformance Refactoration!
  21. 21. Backing up... What is a metric? Measurement assigns numbers based on well- defined meaning - Sometimes the environment must be modified - Special development procedures that track various activities - Wikipedia (paraphrased) You can cheat and use booleans, too
  22. 22. Notes on continuous integration A build system Runs on every code commit Runs tests Reports
  23. 23. Metric examples
  24. 24. PHP Code Sniffer PEAR Package: http://pear.php.net/package/PHP_CodeSniffer Checks conformance of a set of files against a series of classes called “sniffs”
  25. 25. PHP Code Sniffer $ phpcs /path/to/code/myfile.php FILE: /path/to/code/myfile.php ------------------------------------------------------------------------ FOUND 5 ERROR(S) AFFECTING 2 LINE(S) ------------------------------------------------------------------------   2 | ERROR | Missing file doc comment  47 | ERROR | Line not indented correctly; expected 4 spaces but found 1  51 | ERROR | Missing function doc comment  88 | ERROR | Line not indented correctly; expected 9 spaces but found 6 ------------------------------------------------------------------------
  26. 26. PHP Code Sniffer $ svn commit -m "Test" temp.php Sending        temp.php Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: FILE: temp.php -------------------------------------------------------------- FOUND 1 ERROR(S) AND 0 WARNING(S) AFFECTING 1 LINE(S) --------------------------------------------------------------  2 | ERROR | Missing file doc comment --------------------------------------------------------------
  27. 27. This is important because things are standardized
  28. 28. Measuring code complexity Cyclomatic complexity Directly measures the number of linearly independent paths through a program's source code. a.k.a. 1 + the number of times it branches
  29. 29. Measuring code complexity
  30. 30. Measuring code coverage
  31. 31. Measuring documentation coverage Check it out @ http://thechaw.com/api_generator
  32. 32. Measuring documentation coverage Check it out: http://thechaw.com/api_generator A series of rules Assigns weights based on docblock content and various docblock tags
  33. 33. Measuring documentation coverage Basic checks: Do doc tags exist? Incomplete @param tags? Do @param tags match actual params? Does it have a @link to the man page?
  34. 34. Profiling
  35. 35. Profiling Get timing / memory usage on every test run Granular, get statistics per test method Using continuous integration, code is profiled on each commit, all on a granular level
  36. 36. Case study
  37. 37. CakePHP 1.2 release cycle 1.2 alpha 1.2 beta 1.2 RC1 1.2 RC2 1.2 RC3 1.2 RC4
  38. 38. Metrics are your canary in the coal mine of your development cycle
  39. 39. By tracking profiler stats (and other metrics), we can see trends over time, and catch problems before they become problems
  40. 40. Plus, who doesn’t like pretty graphs?
  41. 41. Finding things to measure CakePHP Inspector class CakePHP Parser class Based on the awesome work of Sean Coates http://github.com/scoates/tokalizer
  42. 42. Finding things to measure
  43. 43. Finding things to measure
  44. 44. Finding things to measure
  45. 45. Finding things to measure
  46. 46. Finding things to measure
  47. 47. In a dynamic language like PHP, this is a hard problem.
  48. 48. However, deep code introspection allows us to ask & answer some very interesting questions
  49. 49. Project mess detection in PHPUnit
  50. 50. Beyond copy-paste detection & into pattern recognition
  51. 51. High-level refactoring tools
  52. 52. Can “good code” be quantified??
  53. 53. Good vs. good enough vs. the economy

×