A good software team knows to talk openly about the code. One suggestion is to get together once a day, maybe at day end, to just talk about or look at some code, even if you are already pairing. The get-together need not take long nor be formal in any manner. Fifteen to thirty minutes should be sufficient. Toss some code up on the wall using an LCD projector and have at it.
Initially, such discussions can be touchy, as critique can be mistakenly viewed as insults or attacks. Over time, the regular exercise of discussing code should form a group that better understands how to communicate effectively with each other.
What to talk about? I brainstormed some ideas for a specific set of teams, things I knew they needed to discuss, and provide that starter list here. Given the almost limitless number of reasons to talk about the code, there is little excuse to forego the forum.
-
“here’s something cool that I did today!”
-
“how could I better express this test?”
-
“here is a mocking technique I found valuable”
-
“this test didn’t make sense to me”
-
“this area of the code concerns me”
-
test granularity
-
test naming
-
BDD
-
how TDD changed my design
-
naming standards
-
coding standards
-
warning standards
-
JUnit 4.4+: Hamcrest matchers, theories, etc.
-
“we’re not writing enough tests”
-
code coverage (taking a look at the actual lines exercised by tests)
-
WTFs in the code or test. Can be amusing, but watch the toes!
-
test execution speed. Splitting into slow/fast suites.
-
identifying and speeding up slow tests
-
test smells
-
various forms of test double (see XUnit Patterns)
-
simple design vs SOLID
-
“we’re not refactoring our production code enough”
-
“we’re not refactoring our tests enough”
-
object mothers for tests
-
“the build is a pain in the rear”
-
looking at a new mock tool like Mockito
And so on. Perhaps get a volunteer (or two) to “open” a topic each week. They talk for a few minutes, and then you open things up for group discussion.
