Comments on: Is peer code inspection worthwhile?

By: Eduardo

Eduardo — Thu, 14 Apr 2011 15:59:42 +0000

This links up nicely to another topic I have covered in my blog, peer programming, as proposed by Extreme Programming and other methodologies. I believe it’s all in the experience level of the people doing the review (or coding) and the risk management related to the project.

For example: why would you review a printf implementation? If it’s a new processor, new RTOS and a freshout programmer, it probably makes sense.

Another thing: experienced (meaning: good and experienced) will know their own limits, will know when to request a peer review, unexperienced programmers will not, and will usually assume their implementation is ideal.

To me, it’s all in the team. A good development team will have enough experienced personnel to drive the team towards excellence. That is: they’ll be able to coach the newer members just enough so that they don’t micromanage, but create a good sense of team. Remember: good manufacturing NEEDS good processes, good development NEEDS good people, and processes are only a tool. Processes shouldn’t overpower innovation and programming skills in development teams.

By: J.C.R. @ LI

J.C.R. @ LI — Mon, 11 Apr 2011 16:56:40 +0000

There is some rules that can be appropriate when using a distributed version controlling system:
* Each new feature have his own branch, even if it’s just local to the developer.
* Each feature is a list of comprehensive patches.
* Each patch change a single aspect of the work to be done, with a message explaining the intention.
* The branch must be fully tested and checked with automatic tools before submitted for review.
* Patches are reviewed separately, one by one.
* If reviewers sign-off all the patches, then the branch is merged into the main tree.
The concept force to make patches that are easy to understand by others. Eventually, the “others” is sometimes ourself days or months later…

By: N.M. @ LI

N.M. @ LI — Mon, 11 Apr 2011 16:56:06 +0000

It saves a lot of time in peer view if everyone follows strictly the coding standard and peer view carried once every week before too much coding has taken place

By: D.G. @ LI

D.G. @ LI — Mon, 11 Apr 2011 02:07:27 +0000

I just started a new discussion about whether design is time worthy.

I might have started to pollute this thread which I think is about inspection techniques and lessons learned. One of my lessons was that finding defects during inspection exposes opportunity for design improvement.

By: S.R. @ LI

S.R. @ LI — Mon, 11 Apr 2011 02:07:01 +0000

Especially with a so-called agile (read: little or no documentation) process, peer code review is essential. You can argue with people until you pass out about whether or not they should write a design spec first. I prefer to remain conscious. But if your process includes a required review before any code gets committed to the trunk, then you’ve at least got some guarantee that there’s a line that’s uncrossable without scrutiny of design. I earned my chops in the “quality” 80′s when it was actually fashionable to document your design before writing code. Today it seems impossible to fight the trend toward document-free coding, at least in my company. Without required peer code review there would be chaos. Just wondering, am I really a dinosour, or do others share my preference for up-front design reviews?

By: V.S. @ LI

V.S. @ LI — Mon, 11 Apr 2011 02:06:42 +0000

Peer code review should be conducted very often say every 15 days or 500 lines of code. ideally the developer should develop Unit Test cases first (Test driven Development) and then the code. Getting both reviewed (with no bureaucracy of team lead etc) can really help improve the code quality and ensure defects are caught very early

By: D.H. @ LI

D.H. @ LI — Mon, 11 Apr 2011 02:06:19 +0000

Code reviews make the code you generate better. When you know it will be looked at you do a better job. That’s on top of all the downstream benefit

By: M.S. @ LI

M.S. @ LI — Mon, 11 Apr 2011 02:05:59 +0000

It is SOP that nothing gets checked in to source control until it has been peer reviewed using Code Collaborator. I would respectfully disagree with comments that a necessity for code reviews is an indication of a poor architecture or design. Another set of eyeballs is always a good idea. Besides the opportunity to improve the quality of the code being added or changed, it is an opportunity to catch the unintended consequences of a code change in a complex system. When production volumes are high mistakes become very costly in the repair bay or worse yet in the customers home..

By: J.C.R. @ LI

J.C.R. @ LI — Mon, 11 Apr 2011 02:05:40 +0000

The vast majority of the projects are growing in evolutionary way: there is no clear split between the design activity and the code programming. Look at most of open source project: the design of a new feature is a collection of patches that will be merged into the trunk when it is ready. Often the design and code are improved by a number of test and review cycles done by others.

By: D.G. @ LI

D.G. @ LI — Mon, 11 Apr 2011 02:05:13 +0000

Code reviews are most productive in the absence of design. When the design is solid the code simply conforms or it doesn’t. If code reviews are needed for communication purposes then architecture and design are both lacking. It is always a good idea to get someone to double check your work. Everyone makes mistakes in the details at least some of the time. Still, if important issues are being discovered in code reviews then look to improve design skills/tools/methodology.