2

I'm currently rolling out some quality principles and associated techniques in our development team. What proved essential in my last projects was the four-eyes-principle, i.e. that before each commit, the piece of code is presented to a peer that is being aware of the quality principles of the project.

However, in this new team, the development is taking place distributed within different physical locations, so simply switching room and present code is not possible before checking in to version control.

The consequence would be that code goes into version control that might have flaws in it just for the purpose that the other peer can review it.

We're developing C# code within Visual Studio and use Subversion as version control system.

Any idea about methods or tools how to overcome that problem?

Improve this question
4
  • The able to direct you to more specific examples the following info would help: What kind of version control are you using? What IDE / programming language is the team using?
    – Niels van Reijmersdal
    Commented Apr 8, 2015 at 8:02
  • The "Four eyes principle" is a terrible name. There are many people with poor eyesight who are skilled software developers. Some have only one eye that works so would you discriminate against these people and require four of them? Some people have no eyesight, how many these people would be required?
    – AdrianHHH
    Commented Apr 9, 2015 at 12:34
  • 1
    Agreed, the "Two-man rule" is better in this case. en.wikipedia.org/wiki/Two-man_rule
    – Niels van Reijmersdal
    Commented Apr 10, 2015 at 8:33
  • 1
    @AdrianHHH Four eyes is not a terrible name. A very common expression says "let's get another set of eyes on this". Naturally, someone with one or no eyes can still be "another set of eyes". Most (as in 99,997 out of 100,000) people are born with two eyes (even if non functioning). C'mon now. Generally, people prefer general neutral terms, and "four eyes" fits the bill.
    – corsiKa ♦
    Commented Apr 10, 2015 at 15:58

1 Answer 1

Reset to default
8

Branch the code before review and merge it into the main release branch after the review is accepted/completed. See this blogpost for more idea's: http://share.ez.no/blogs/arne-bakkebo/branching-and-code-review-procedures-qa-4

For Subversion you can look into simulation shelve-sets and let the sets be reviewed before checked-in: http://jason.famularo.org/simulating-tfs-shelvesets-in-subversion.

Better would be to upgrade Subversion to either TFS or Git and use either TFS reviews or Git branches.

Pre-commit reviews

Some tools support pre-commit reviews, like:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.