Measuring Your Code 2.0

2,962 views

Published on

One of the biggest problems of software projects is that, while the practice of software development is commonly thought of as engineering, it is inherently a creative discipline; hence, many things about it are hard to measure. While simple yardsticks like test coverage and cyclomatic complexity are important for code quality, what other metrics can we apply to answer questions about our code? What coding conventions or development practices can we implement to make our code easier to measure? We'll take a tour through some processes and tools you can implement to begin improving code quality in your team or organization, and see what a difference it makes to long-term project maintainability. More importantly, we'll look at how we can move beyond today's tools to answer higher-level questions of code quality. Can 'good code' be quantified?

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

No Downloads
Views
Total views
2,962
On SlideShare
0
From Embeds
0
Number of Embeds
82
Actions
Shares
0
Downloads
56
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Measuring Your Code 2.0

  1. 1. Measuring your code A talk by Nate Abele @nateabele nate.abele@gmail.com
  2. 2. Feedback http://joind.in/1601
  3. 3. Confession
  4. 4. Coercion, red bars & broken windows
  5. 5. Continuous
  6. 6. Goal: Perfection
  7. 7. Or at the least, continuous improvement
  8. 8. a.k.a. (kaizen)
  9. 9. What people usually think Estimating costs Projecting deadlines Managerial BS!
  10. 10. Client Spec Sheet some paraphrased) (actual bullet points, Flash intro with no load time User account logins, password optional Ajax chat “Like Google”
  11. 11. ...and my personal favorite Social network
  12. 12. Measurement is an essential element of management; there is little chance of controlling what we can not measure. - Wikipedia, “Software metric”
  13. 13. Wherefore... (WTF) ?
  14. 14. “Engineer” & “architect”
  15. 15. Cognitive Dissonance * Engineers deal with tangible, immutable constraints, like gravity The practice of developing software is an inherently creative discipline * Thank you, Jones
  16. 16. 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
  17. 17. 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
  18. 18. What can we measure?
  19. 19. Code!!
  20. 20. More specifically... Unit test coverage Complexity Speed Documentation
  21. 21. More specifically... Standards conformance Refactoration!
  22. 22. 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
  23. 23. Notes on continuous integration A build system Runs on every code commit Runs tests Reports
  24. 24. Metric examples
  25. 25. 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”
  26. 26. 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 ------------------------------------------------------------------------
  27. 27. 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 --------------------------------------------------------------
  28. 28. This is important because things are standardized
  29. 29. 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
  30. 30. Measuring code complexity public function render() { $code = null; if (isset($this->headers['location']) && $this->status['code'] === 200) { $code = 302; } if (!$status = $this->status($code)) { throw new Exception('Invalid status code'); } $this->_writeHeader($status); foreach ($this->headers as $name => $value) { $key = strtolower($name); if ($key == 'location') { $this->_writeHeader("Location: {$value}", $this->status['code']); } elseif ($key == 'download') { $this->_writeHeader('Content-Disposition: attachment; filename="' . $val } elseif (is_array($value)) { $this->_writeHeader( array_map(function($v) use ($name) { return "{$name}: {$v}"; }, $val ); } elseif (!is_numeric($name)) { $this->_writeHeader("{$name}: {$value}"); } } }
  31. 31. Measuring code coverage
  32. 32. Measuring documentation coverage Check it out @ http://thechaw.com/api_generator
  33. 33. 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
  34. 34. 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?
  35. 35. Profiling
  36. 36. 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
  37. 37. Case study
  38. 38. CakePHP 1.2 release cycle 1.2 alpha 1.2 beta 1.2 RC1 1.2 RC2 1.2 RC3 1.2 RC4
  39. 39. Metrics are your canary in the coal mine of your development cycle
  40. 40. By tracking profiler stats (and other metrics), we can see trends over time, and catch problems before they become problems
  41. 41. Plus, who doesn’t like pretty graphs?
  42. 42. Finding things to measure Lithium Inspector class Lithium Parser class Based on the awesome work of Sean Coates http://github.com/scoates/tokalizer
  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. Finding things to measure
  48. 48. In a dynamic language like PHP, this is a hard problem.
  49. 49. However, deep code introspection allows us to ask & answer some very interesting questions
  50. 50. Project mess detection in PHPUnit
  51. 51. Beyond copy-paste detection & into pattern recognition
  52. 52. High-level refactoring tools
  53. 53. Can “good code” be quantified??
  54. 54. When is “good enough”... good enough?
  55. 55. Technical debt
  56. 56. Incentives and social coercion
  57. 57. Choose your own adventure!
  58. 58. Go write better code

×