A professor of mine asked about the kinds of “reviews” that I have practiced in the industry. They cover a wide range of practices in the verification & validation classes. Times, practices, and industry has changed and so some of these are more popular and others are practically unheard of anymore.
- Ad Hoc Review
- Peer Desk-Check
- Pair Programming
- Team Reviews
- Formal Inspections
I worked on contract teams, at a startup, and in the enterprise on enterprise software, mobile applications, and medical devices. So, I have some different perspectives, but it boils down to the following three practices.
One of the teams I worked on was part of a rescue project. We rewrote the control software for a medical device. It was late, over-budget, and we had nothing salvagable except the theory of operations. We practiced pair programming on nearly all production and test code. This allowed us to come up to speed together and avoid a single point of failure or bottleneck (“We can’t complete this module because Chris is on vacation!”). We improved our “functional redundancy” or “resiliency” in this way. We were able to design and code at the same time (navigator/driver). We worked quickly and could iterate several times on a design or module in one pairing session.
At most of my enteprise jobs, the only practice formally enforced was [code review]1. There never was much informal review. Folks would occassionally ask for a “desk check” or the like. We often used separate repository browser tools (a popular one is Crucible) that support discussion over diffs, workflow (open, in-progress, completed), and integration with the issue tracker. In most of these places, the code was mediocre in quality and design. I don’t know that code reviews were the cause. An after-coding review may point out consistency, formatting, or glaring syntactical issues, but it cannot usually improve design.
In my open-source experience, we used pull requests from forks or branches. This method looks like discussion over diffs on steroids. You can view diffs and commit messages, carry on inline commentary, and continue to add commits to the request to address comments. GitHub simply has one of the best interfaces, which can make or break an energetic, deep review. A pull request also acts as a gate. The code is fully committed (safe) and reviewable (good), but it’s not in the “master” branch yet. The owners of the repository/branch get control of that decision.
http://arlobelshee.com/using-code-review-to-support-change/ (“Arlo Belshee just wrote about using code reviews to support change.”) ↩