CSCE 315 Lecture 23

« previous | Wednesday, March 21, 2012 | next »

Code Inspection

Prepare stuff (line numbers are helpful)
Overview: Author gives brief explanation if necessary
Preparation: Reviewers work alone to scrutinize for errors (can play different roles such as user or designer; read code from top-down or bottom-up)
Inspection Meeting: reviewer explains what happens, moderator keeps things focused, scribe records problems, their type, and severity, don't discuss solutions
Sometimes hold a third-hour meeting to discuss solutions
Report: Moderator orders list of errors recorded by scribe and updates checklist for future inspections
Keep data on time spent and number of errors
Follow-up: Moderator verifies that work assigned was carried out

Evaluate whether code reviews are actually useful.

The point of inspection is to improve code; NOT to

Moderator needs to keep control of discussion

Author needs to be able to take criticism of code without debating. Some things may not "really" be errors.

Reviewer needs to realize that code is not theirs.

Author walks through code and accepts any criticism

Similar to code review, only geared toward informal

Code reading is where author gives code to someone else to review; also very informal.

Standardize coding style
Don't force pairs for easy tasks
Rotate pairs and assignments frequently
Use good matches (avoid personality conflicts and major differences in speed/experience)
Set up good work environment
At least one member should be experienced

Aim toward designing code that runs on multiple machines, but that's a C++ issue.

Abstraction (Strategy and Abstract Factory patterns help)