What is code quality?
Not talking about the little things like “you missed a cfQueryParam there” but more “is it going to stand up to the test of time” so that things last.
Steve McConnell
1 of 3 most influential people in the software industry (Bill Gates and Linus Torvald as the other two)
“Testing does not along make better software.”
“If you want to lose weight, do not buy a new scale; change your diet. If you want to make better products, do not test more; code better.”
Improving Code Quality
- code standards guidelines (note: guidelines was spelled wrong on the slide)
- pair coding
- user groups
- test driven development
Code (Peer) Reviews
Peer in the sense that we are not reviewing who wrote the code but more working as a group of peers to make the code better. Its easy to make it personal but you need to make sure that is left out. Don’t say things like “why did you do it this way?” but rather “I don’t understand this section.”
Key: Don’t use “you” statements.
Goal?
Understanding the goal will help get to the finish line.
- drive quality (obvious goal)
- build a team (important but hard)
- increase fungibility (ability to cross training)
Self Review
Have something to talk to. Actually speaking out loud helps immensely because your brain processes things differently when it hears it than when you just think to yourself. Who/what you are talking to does not matter.
Informal Peer Reviews
- design validation
- agile side of desk
- talking out loud
- “manage up”
One method is to initiate on your own code. “Hey Erin, would you take a look at some of this code?” She can find mistakes but also learns how to do some things.
Another way is to walk over and ask what another developer is working on. This gives you the opportunity to get out and talk to someone which helps build a team but also to learn/teach something in both directions.
Building team dynamics should also be part of your job description.
What about the un-passionate types? They are normally the people that just want to get things done and don’t care about the quality. This is quite hard.
Rules:
- Everyone learns differently (be inviting to other styles of learning)
- Create comfortable communication
- Follow through (everything else ONLY works if you do this)
Formal Peer Reviews
- review code ahead of time
- don’t spend more than 90 minutes
- meetings should be a recap
- tools help
You do not want this http://www.frequency-decoder.com/2009/05/29/wtf-s-minute but rather a collaborative effort to make the code better. You want a to do list in order to make the code production ready. You do not want the experience to get personal towards the coder at all. The leader is in charge of making this is not done. Side conversations can happen if needed because if you reprimand someone in front of the group, you are making it personal as well.
? don’t defend your own code during the meeting.
Code Review Tools
- Crucible by Atlassian. <$5000. has very good version control integration.
- Code Collaborator by SmartBear. $1299/concurrent user w/ 10 user minimum
But really you don’t need a tool, if you have some sort of version control and eclipse then you have all you need.
Key: Don’t dredge up the past!
Full slides at Adam’s blog http://cfrant.blogspot.com/
