What is good code? Evaluating Code Quality (workshop)

I've facilitated this workshop in different communities and events, from October 2017 to June 2018. Companion material (notes, resources…) including slides used in specific editions can be found @ https://github.com/dcarral/good-code.

Workshop summary:

After introducing the main topic (“What is good code?”), participants are asked to solve a simple algorithmic problem (the kata) pairing in their programming language of choice.

Once the coding session is over, it’s time for the “show & discuss” section, where volunteers show and explain their solutions to the group. Together, we discuss tradeoffs, design choices, etc.

Afterwards, concepts like software metrics and static code analysis are gently introduced before discussing even more solutions to the original problem and checking if the numbers align with the previously stated opinions.

The wide range of potential approaches (under slight time pressure, in several programming languages and with different development environments) provides an interesting context to discuss topics like:

– Software development concepts such as duplication tolerance, refactor aggressivity, layers of indirection, conditionals usage, KISS (Keep It Simple, Stupid) / DRY (Don’t Repeat Yourself), etc.

– (XP) eXtreme Programming practices: simple design, pair programming, refactoring, TDD (Test-Driven Development), etc.

Transcript

1. What is good code? Evaluating code quality Daniel Carral Barcelona on Rails (@ XING), 02/15/2018
3. github.com/dcarral/good-code
4. Agenda ➔ Intro ➔ Craft Let’s solve the problem! ➔ Show & discuss Which approach did you use? Why? ➔ Evaluate Opinion vs facts What do the numbers say? ➔ Retrospective
5. What is good?
7. Good?
9. Good? Better?
11. Craft Coding Dojo
12. How many dojos?
15. TDD & refactoring
16. Pair programming
17. Simple design
18. Kata 99 bottles of beer
19. Clone & code :) github.com/dcarral/99bottles-polyglot
20. (until 20:30h) Clone & code :) github.com/dcarral/99bottles-polyglot
21. Time over :)
22. Show & discuss (or not ;)
23. How did you solve it? Why? Reminder The goal is not to judge our coding skills. We’re discussing how to evaluate code quality.
24. github.com/dcarral/99bottles-solutions
25. Agenda ➔ Intro ➔ Craft Let’s solve the problem! ➔ Show & discuss Which approach did you use? Why? ➔ Evaluate Opinion vs facts What do the numbers say? ➔ Retrospective
26. Evaluating code quality
27. Based on opinion
29. In your opinion, what is “good code”? • “Easy to understand and read. Easy to test.” • “SOLID” • “Passes the squint test :)” • “Quality transcends description”
30. Based on facts
31. Software metrics “A software metric is a standard measure of a degree to which a software system possesses some property.”
32. Why measure? “You cannot control what you cannot measure.”* — Tom DeMarco * Apparently, he regrets having said this (thanks David!)
33. Some metrics • Ca 1960: LOC • 1976: Cyclomatic complexity • 1997: ABC size
34. ABC • Assignments • Branches (of control) • Conditions
35. “Confessions of a Ruby Sadist”
36. 4 more solutions
37. What do the numbers say? Solution LOC Flog total Flog worst bit #1 Incomprehensibly concise 19 42.5 36.2 (#verse) #2 Speculatively general 63 54.8 28.5 (lambdas) #3 Concretely abstract 92 67 15.3 (#challenge) #4 Shameless green 34 25.6 19.3 (#verse)
38. Why metrics? “Metrics are fallible but human opinion is no more precise. Checking metrics regularly will keep you humble and improve your code.” — Sandi Metz, Katrina Owen
40. sandimetz.com/99bottles/postcard
41. * Disclaimer: Some people don’t like it (at all). Think twice before purchasing it ;)
42. Retro time
43. … surprised me. I’ve learnt… I’d like to start doing… Feedback :)
45. • Coding dojos • TDD • Refactoring • Pair programming • Simple design • Zen & the art of motorcycle maintenance • Clean Code • eXtreme Programming explained • 99 bottles of OOP • Beautiful code • Software metrics • LOC • Cyclomatic complexity • ABC size @dcarral dcarral.org