Measuring Your Code

  • 2,301 views
Uploaded 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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,301
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
33
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Measuring your code A talk by Nate Abele @nateabele nate.abele@gmail.com
  • 2. Confession
  • 3. Coercion, red bars & broken windows
  • 4. Continuous
  • 5. Goal: Perfection
  • 6. Or at the least, continuous improvement
  • 7. a.k.a. (kaizen)
  • 8. What people usually think Estimating costs Projecting deadlines Managerial BS!
  • 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. ...and my personal favorite Social network
  • 11. Measurement is an essential element of management; there is little chance of controlling what we can not measure. - Wikipedia, “Software metric”
  • 12. Wherefore... (WTF) ?
  • 13. “Engineer” & “architect”
  • 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. 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. 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. What can we measure?
  • 18. Code!!
  • 19. More specifically... Unit test coverage Complexity Speed Documentation
  • 20. More specifically... Standards conformance Refactoration!
  • 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. Notes on continuous integration A build system Runs on every code commit Runs tests Reports
  • 23. Metric examples
  • 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. 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. 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. This is important because things are standardized
  • 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. Measuring code complexity
  • 30. Measuring code coverage
  • 31. Measuring documentation coverage Check it out @ http://thechaw.com/api_generator
  • 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. 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. Profiling
  • 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. Case study
  • 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. Metrics are your canary in the coal mine of your development cycle
  • 39. By tracking profiler stats (and other metrics), we can see trends over time, and catch problems before they become problems
  • 40. Plus, who doesn’t like pretty graphs?
  • 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. Finding things to measure
  • 43. Finding things to measure
  • 44. Finding things to measure
  • 45. Finding things to measure
  • 46. Finding things to measure
  • 47. In a dynamic language like PHP, this is a hard problem.
  • 48. However, deep code introspection allows us to ask & answer some very interesting questions
  • 49. Project mess detection in PHPUnit
  • 50. Beyond copy-paste detection & into pattern recognition
  • 51. High-level refactoring tools
  • 52. Can “good code” be quantified??
  • 53. Good vs. good enough vs. the economy