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.

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”

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. 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. 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. What can we measure?

19. Code!!

20. More specifically...
Unit test coverage
Complexity
Speed
Documentation

21. More specifically...
Standards conformance
Refactoration!

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. Notes on continuous integration
A build system
Runs on every code commit
Runs tests
Reports

24. Metric examples

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. 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. 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. This is important because things
are standardized

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. Measuring code complexity

31. Measuring code coverage

32. Measuring documentation coverage
Check it out @ http://thechaw.com/api_generator

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. 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. Profiling

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. Case study

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. Metrics are your canary in the coal
mine of your development cycle

40. By tracking profiler stats (and other metrics),
we can see trends over time, and catch
problems before they become problems

41. Plus, who doesn’t like pretty graphs?

42. Finding things to measure
CakePHP Inspector class
CakePHP Parser class
Based on the awesome work of Sean Coates
http://github.com/scoates/tokalizer

43. Finding things to measure

44. Finding things to measure

45. Finding things to measure

46. Finding things to measure

47. Finding things to measure

48. In a dynamic language like PHP, this
is a hard problem.

49. However, deep code introspection
allows us to ask & answer some
very interesting questions

50. Project mess detection in PHPUnit

51. Beyond copy-paste detection & into
pattern recognition

52. High-level refactoring tools

53. Can “good code” be quantified??

54. Good
vs.
good enough
vs.
the economy