Code Review vs. Code Walkthrough vs. Code Inspection
In Code review and code walkthrough the author of the material being reviewed facilitates walk-Through. The participants are led through the material in one of two formats; the presentation is made without interruptions and comments are made at the end, or comments are made throughout. In either case, the issues raised are captured and published in a report distributed to the participants. Possible solutions for uncovered defects are not discussed during the review.
A knowledgeable individual called a moderator, who is not a member of the team or the author of the product under review, facilitates inspections. A recorder who records the defects found and actions assigned assists the moderator. The meeting is planned in advance and material is distributed to all the participants and the participants are expected to attend the meeting well prepared. The issues raised during the meeting are documented and circulated among the members present and the management.
Technical Code Review
History
A technical code review is a discussion meeting that focuses on technical content of a document. it is led by a trained moderator, but also can be led by a technical expert.Compared to inspections, technical code reviews are less formal and there is little or no focus on defect identification on the basis of referenced documents. The experts that are needed to be present for a technical review can be architects, chief designers and key users. It is often performed as a peer review without management participation.
In the software development life cycle, code reviews are a stage where programmers carefully verify each other’s code for any errors, odd formatting in code, or discrepancies with system requirements that could cause more severe issues during software integration. It is the systematic study of computer source code, also known as peer review.
The specific goals of a technical review are:
- Evaluate the value of technical concepts and alternatives in the product and project environment.
- Establish consistency in the use and representation of technical concepts.
- Ensuring at an early stage, that technical concepts are used correctly.
- Inform participants of the technical content of the document.
In the 1970s, Michael Fagan started publishing several papers for IBM on software inspections for the Waterfall approach, which helped establish code review as a common practice.
The Fagan Inspection was a process developed by Fagan in which developers engaged in a formal meeting with four primary steps: initialization, preparation, discussion, and corrections.
While approaches have changed in response to evolving technology and development methodologies, the core goal of code reviews has remained the same. Analyzing the source code as a team fosters a sense of collective responsibility for the software’s advancement.
How Technical Code Review Works?
Typically, the code review process evaluates four key areas:
- Quality of documentation
- Code issues
- Formatting consistency with the overall software design.
- Compliance with coding standards and project specifications.
After a developer completes work on an issue, another developer reviews the code and thinks about topics like:
- Are there any evident logical errors in the code?
- Are all scenarios fully implemented based on the requirements?
- The new code has been put through new automated tests; are they sufficient?
- Is it necessary to rewrite existing automated tests to accommodate code changes?
- Is the new code consistent with existing style guidelines?
The reviewers should be entirely disconnected from the project under review, as this maximizes impartiality and guarantees the code is legible and maintainable even by those who are unfamiliar with the project. And reviewers will use a standard checklist to identify common errors and validate the code to the company’s coding standards.
Why code reviews are done?
When we need to identify security flaws, Code review is beneficial. Specialist application packages can aid this approach. Automated code review simplifies the process of evaluating source code for vulnerabilities such as buffer overflows, race conditions, memory leaks, size violations, and duplicate statements. Another common application of code review is testing.
Code reviews should be integrated into an organization’s existing process.
Simple Example — A code review should be started if a team uses task branching processes after all the code has been produced and all the automated tests have been run and passed before the code is merged upstream.
By doing this, the primary development stream is shielded from bad coding mistakes, and the code reviewer’s time is devoted to looking for things machines miss.
Advantages
Code reviews offer many significant advantages, such as:
- Improvement of code quality — Code reviews improve code quality by finding problems before they become unmanageable and enforcing consistent standards. This results in powerful software composed of components for seamless integration and functionality.
- Promotes Knowledge Transfer — The regular study of source code enables programmers to pick up more dependable methods and best practices.
- Supports teams in improving documentation — Code reviews also assist teams in creating better documentation, making it easier for developers to add new features and upgrade current ones in the future.
- It simplifies QA testing — Another advantage of having uniform standards is easier-to-understand source code for specialists and testers.
Code Walkthrough
A walkthrough is conducted by the author of the ‘document under review’ who takes the participants through the document and his or her thought processes, to achieve a common understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or cannot easily understand software development documents. The content of the document is explained step by step by the author, to reach consensus on changes or to gather information.
The participants are selected from different departments and backgrounds If the audience represents a broad section of skills and disciplines, it can give assurance that no major defects are ‘missed’ in the walk-through. A walkthrough is especially useful for higher-level documents, such as requirement specifications and architectural documents.
The specific goals of a walkthrough are:-
The meeting is usually led by the author of the document under review and attended by other members of the team.
Review sessions may be formal or informal.
To explain and evaluate the contents of the document.
Before the walkthrough meeting, the preparation by reviewers and then a review report with a list of findings.
To establish a common understanding of the document.
The scribe, who is not the author, marks the minutes of meeting and note down all the defects/issues so that it can be tracked to closure.
To examine and discuss the validity of proposed solutions and the possible alternatives.
The main purpose of walkthrough is to enable learning about the content of the document under review to help team members gain an understanding of the content of the document and also to find defects.
To present the document to stakeholders both within and outside the software discipline, in order to gather information regarding the topic under documentation.
Code Inspection
Inspection is the most formal review type.It is usually led by a trained moderator (certainly not by the author).The document under inspection is prepared and checked thoroughly by the
reviewers before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists. In the inspection meeting the defects found are
logged.Depending on the organization and the objectives of a project, inspections can be balanced to serve a number of goals.
The specific goals of a Inspection are:
• help the author to improve the quality of the document under inspection.
• remove defects efficiently, as early as possible.
• improve product quality, by producing documents with a higher level of quality.
• create a common understanding by exchanging information among the inspection participants.