Hello
I have a site being developed, in aspx / dot net, there a few developers, the lead programmer insists on “code reviews” and they take a long time. What are they?
What is “code review”?
If other developers test along the way and debug their code, and it works fine on one anothers machines and fulfills the functionality required then what is the role of “code review”?
Thank you in advance for any help
It’s quite literally a review of the code that has been written. Usually in Software Development projects the Lead or Principal Developer will want to conduct code reviews, usually using things like Version Control Pull Requests. The actual process of reviewing code is of course down to the whoever is the reviewer, maybe they are looking for something specific, or they have a general set of rules and standards that the code needs to live up to. If it’s taking a long time then the process is probably not very good, or the chunks up for review are simply too large - I find that the best code review is on small additions / patches of recent work that is fresh in the memory of the reviewer (who is likely to have been part in the system architecture planning).
As for just accepting that the code runs on the developers machine, the reviewer may be looking at solution quality, e.g. just because it works does not mean that the solutions is good and optimal. Furthermore the reviewer may have experience regarding things that may or may not work on different systems and setups and therefore the fact that it works on the developers machine is not enough.
In short, the process of Code Review is an individual process that is important, but if it’s taking so long that it significantly slows down development then the process may be flawed or the reviewer does not have the adequate experience to quickly spot whether or not an implementation is “good enough” to pass the review.
Code review is the best way to catch bugs before code goes into production. It also helps developers share knowledge between each other, unify coding styles, and
There are bugs automated tests won’t be able to find. Additionally, regular code review can help developers think of better ways to solve problems.
Code review can take a while, sure, but the payoff is absolutely worth it.
<snip/>
Code review also ensures that everyone is following the same in house standards with the code that they write. This will cover lots of things that do not make any difference to whether the code works or not such as indentation. It basically ensures that everyone’s code is written the same way so that everyone can maintain all the code as if they were the sole programmer responsible for writing it.
On top of what has been mentioned code reviews are wonderful opportunity for you to learn from the senior developers – there is a lot more than meeting the functional requirements to software development.
I’m currently in a dev team where Code Review is essential. Previous jobs, I did code review during meetings or other type of face-to-face meetings. Now, there are plenty of tools to perform code review where a developer can do it anytime. The cons is that un-reviewed code must be checked in. After that other developers can start looking at your changes. If it’s to a point that it needs a re-write up then all you need to do is rollback the check-ins. I really do like code review since other catch my stupid mistakes but I don’t get why we don’t code review our techlead/architect codes…just seems a bit unfair.
In a perfect world the tech leads / architects are reviewing each other.
It is a phrase in the software development process in which the authors of code and perhaps quality assurance mentors get together to review code. Code review is systematic examination of computer source code.
Code review fall into three main categories:
(1) pair programming,
(2) formal code review and
(3) lightweight code review…