Code ClubAn internal presentation from 2002

Dr Simon PriceAcademic Research IT Manager

1

Developers, welcome to Code Club.

• First rule of Code Club is you do not talk about Code Club.

• Second rule of Code Club is YOU DO NOT TALK ABOUT CODE CLUB!

"Doh!"

Initial idea: a "coding clinic " for our techies

• Objectives:• meet regularly to review code• produce some ID coding standards• share experiences and expertise

Getting Started

Kick-off meeting (15 Oct 2002)

• "Real" rather than "virtual" meeting.

• The name Code Clinic - suggestive of some embarrassing

compliant that you don't want to mention in public.

• We have a Kieren Pitts in the team and edit distance

distedit (“K. Pitts”, “B. Pitt”) is small, so...

• …Code Club was born.

Kick-off Decisions

• Start fairly informally and build up structures/documents as required.

• Meet every 2 weeks. (Decide if this is the right frequency once we've run for a few meetings).

• Each meeting, someone will present code for review (emailing out beforehand with an explanation if needed).

• Review from various perspectives – eg. efficiency, standards, readability, design, reuse, documentation.

Rule #3Third rule of Code Club, someone yells stop, goes limp, taps out, the review is over.

• It's not managerial• It's not personal*• It's about code

* unless you forget the donuts!!!

Kick-off Ideas

• Standards for coding• where possible across languages• sometimes language-specific (eg. perl conventions for capitals

being reserved for specific purpose)• will emerge from review meetings and grow over time • defining standards will have an impact on the amount of code

we can review in a given time (ie. reducing it);• written standards will make it easier for new dev. staff to get

up to speed and learn how we work

More Ideas

• Code Repository • We all keep snippets of code for reuse (or know where to find

them in our old projects).• One of the useful things the code club could do is identify

potential reuse...• building up a shared repository. (A simple version would just

be a searchable list of what to find where!)

Ahead of First Meeting

• Reviewee emailed CC members• code for review• explanation• reminder of meeting details

First CC Meeting (29 Oct 2002)

Present: IMS, ETC, SNP, KP, PS

Summary: Reviewed the main path VTS3/Calnet the code looking for ways of improving the efficiency (particularly - reducing execution time). Also looked at style, design, readability, mistakes, areas for re-use etc.

Files reviewed: gen.pl, constants.pl, util.pl, ...

Rule #4Forth rule only two guys to a review.

Well, about 5-6 is a manageable number.

More Decisions

• This was a worthwhile exercise!• Use Bugzilla as way of recording/tracking issues raised in reviews.• Person whose code will be reviewed responsible for:

• booking room• taking notes at the meeting• entering issues into Bugzilla• circulating brief note of meeting by email • and...

Rule #5Fifth rule: one review at a time, fellas.

Yes, but we do start with a report back on the previous review from the reviewee.

Rule #6Sixth rule: no shirts no shoes.

Worrying, huh?

Rule #7Seventh rule: Reviews will go on as long as they have to.

Well, we book the room for 2 hours.

Rule #8And the eighth and final rule: If this is your first day at Code Club, you have to review.

• Actually, we each take a turn to provide the code for review.• Reviewee books room, circulates code (& notes) and

provides donuts.• Reviewee leads through the code and takes notes of issues

raised.

Where Next?

• Walk before running, but...

• ... CC is producing standards and guidelines documents• initially, internal facing• but eventually, external facing

• ... CC might also experiment with a formalised process called Software Inspections

Software InspectionsDesign and code inspections to reduce errors in program development, Michael E. Fagan, IBM Systems Journal, Vol. 15(3), pp 182-211, 1976.

• Substantial net improvements in programming quality and productivity.• Formal inspections of design and code.• Systematic and efficient design and code verification process.• Well-defined roles for inspection participants.• Inspection data is categorized and made suitable for process analysis.• By using inspection results, a mechanism for initial error reduction

followed by ever-improving error rates can be achieved.

Recommended Reading

Software Inspection, Tom Gilb and Dorothy Graham, Addison-Wesley, 1993.

• historical background• benefits and cost• individual phases of inspection• inspection leader• installation and training• case studies

Summary

• Early days, but...• enjoyable• going well so far• but yet to tackle issue of bug resolution