As codebases get larger, what is being done to ensure that code reviews are done? I mean I hear second hand about the mean comments from Linus Torvalds about RC code quality in Linux all the time. To paraphrase him, RC code should not have as many kernel breaking bugs as they do. And this is in Linux which has a lot of eyes. What about smaller teams?
Code reviews are exactly the problem. Most developers just slap shit together to meet deadline and assume that any errors will be fixed by the review. They do not have the luxury to spend a lot of time doing things "by the book" because if they do, the other developers will look much more productive than they are.
In proprietary environments where I managed a dev team, my guidelines were along the lines of:
1. You, the developer, should not commit code except to private environments until you think it's ready for the end customer -- but with the understanding that extensive stress testing which isn't practical to do for every commit to the general developer branches may find bugs that are not identifiable by simple code review and unit testing because they are architectural in nature - esp. if you didn't do the architectural design of the feature/capability the code was implementing/adding.
2. You, the reviewer, are generally as responsible for bugs that slip through your review and are found in systems test or customer deployment as the original developer is -- but with the understanding that a code review may not catch architectural design problems if the reviewer(s) is(are) not familiar with the subsystems interfaces/implementation where those design problems are buried.
3. You, the developer, are responsible for bugs found in the code review process and those instances will be taken into account in decisions on salary and promotional actions. Valid suggestions that code reviewers make to improve code that works and is rationally coded are not bugs and are not held against the developer unless the developer consistently shows bad judgement and continues to write code that has the same substandard attributes.
Of course, all such guidelines are just that - guidelines to be adjusted to accommodate unique situations.
Larger question of code quality (Score:5, Interesting)
Re: (Score:4, Interesting)
Re:Larger question of code quality (Score:2)
In proprietary environments where I managed a dev team, my guidelines were along the lines of:
1. You, the developer, should not commit code except to private environments until you think it's ready for the end customer -- but with the understanding that extensive stress testing which isn't practical to do for every commit to the general developer branches may find bugs that are not identifiable by simple code review and unit testing because they are architectural in nature - esp. if you didn't do the architectural design of the feature/capability the code was implementing/adding.
2. You, the reviewer, are generally as responsible for bugs that slip through your review and are found in systems test or customer deployment as the original developer is -- but with the understanding that a code review may not catch architectural design problems if the reviewer(s) is(are) not familiar with the subsystems interfaces/implementation where those design problems are buried.
3. You, the developer, are responsible for bugs found in the code review process and those instances will be taken into account in decisions on salary and promotional actions. Valid suggestions that code reviewers make to improve code that works and is rationally coded are not bugs and are not held against the developer unless the developer consistently shows bad judgement and continues to write code that has the same substandard attributes.
Of course, all such guidelines are just that - guidelines to be adjusted to accommodate unique situations.