IT Employment

Ask something
Discussion Locked

What do you think about code reviews?

0 helpful
6 replies

by maryweilage

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
Do you think Scott presents a good case for conducting code reviews, as featured in this week's Application Developer Management newsletter? Please rate this column from 1 to 5, with 5 being the highest rating.

6 replies

by lschneller_y2k

Any steps to find software problems in the early stages of development reduce life cycle costs. However, too many organizations do not support such efforts because of the "tight schedule". In addition, many of these organizations do not have documentation to govern the reviews.

by jrc98

Thought the review was good however also overlooked several other advantages:
-Great teaching tool for newbies
-Assures better maintainability
-Should be reviewed against the objectives
-Metrics should be established and maintained, not for punitive purposes but for continuous improvement
-Lastly, in these days where mobility is increased, there is at least a modicum of knowledge transfer

by roc32k

Code reviews are the last step in our development process. Too often, there is no time left to resolve issues found during the code review. We played with moving the code reviews to an earlier phase of the development process, but that leads to potential un-reviewed code down to the road. Does anyone have any tips or similar struggles?

by mdav

Why not do code reviews at a certain time interval (say, once per week) or at a certain work interval (say, once per every 500 new lines of code)?

Source control can help you identify new code to be reviewed. The time or amount of code interval can be tailored to the size of your projects, but the key is that there is a process, it is consistently implemented, and that it is reviewed for effectiveness after each project.

by sh3th111

I think code reviews should be adopted by dev teams if they haven't already been. No one should expect that a code review is going to catch everything, but many potential issues are resolved just by a developer explaining their code to someone else.It's one of those things that takes time up-front, but saves you time at the end of a project.

by jslezak

In isolation, I don't know of anyone who disagrees with the benefits of code reviews.

However, in a management world where schedule constraints are applied (to provoke creative productivity improvements), preserving schedule time for code reviewsis difficult.

While it is impossible (except in Dilbert's world) to eliminate a coding task from a project schedule, any activity that has a less tangible delivery is much harder to preserve.

Management is often very willing to take on addedrisk of failure by skipping code reviews, to reduce perceived risk of slipping the delivery date. After all, undetected errors might be caught in system testing. In the worst case, undetected errors can be handled in post production support, thus allowing political victory at achieving the delivery date.

This discussion is closed to new replies.