Code Freeze
Code Freeze
Code freeze is an activity where the developers pause to make any further code changes. There are three types of
freezes in SDLC, namely requirement freeze, code freeze, and feature freeze.
Code freeze is stopping any modification in the code for a certain period of time. It generally takes place at the later
stages of SDLC, while the software is being planned for a release. Thus, it is done to limit further changes to the
software just before being shipped to the customers.
A code freeze is implemented to avert a situation where the developers make changes to the code at the last moment,
and impact its stability. As a code freeze is announced, there are no possibilities to make any updates to the software.
However, in case of unavoidable circumstances, where critical bug fixes need to be made, code changes can be pushed
by the developers only after a thorough review and approvals from the project stakeholders. Post code fix stage, the
software is considered ready for production deployment.
This concept is generally followed in the waterfall model of development. However, it is not widely accepted in the
Agile framework since it is redundant there and does not follow the principles of agile. Moreover, it brings down the
software quality and slows down production release.
A code walkthrough is primarily a review meeting initiated by the code author. He reads through the code in
this meeting and other team mates ask questions, point out the coding errors and wherever code standards
are not followed.
The author of the code leads a code walkthrough meeting and other team members attend it. There is no
requirement of a moderator in this meeting. It is an open-ended discussion and there is not much focus on
documentation. In short, a code walkthrough is a type of peer review and forms a part of the static testing.
No formal review process is followed here.
There may be defects in the sections of the code which are not discussed in the walkthrough meeting.
It takes a lot of time to conduct it.
As the author himself leads the meeting, there is no guarantee to the fact that what is being discussed
actually matches with code.
Code Inspection
The code inspection is done to review the code of the software and detect errors in it. It reduces the
probability of fault multiplication and defects being detected at the later stages of SDLC by streamlining the
bug identification procedures. Thus code inspection is a part of code review.
The moderator, author, reader, and recorder forms a part of the code inspection team. All relevant
documents are made available to this team to plan for the future course of actions in this regard. If the
inspection team is unaware of the project, the author gives an introduction of the project and the outline of
code to the inspection team.
The inspection team then checks every piece of code as per the inspection checklists. Once inspection has
been completed, the inspection team informs the findings of the reviewed code to the respective team
members.
It is a time-consuming process.
It requires extensive planning and execution.
The code inspection checklists followed in various projects, and organizations may differ from one another
based on the multiple factors. Also, the checklist items for code inspections are revisited frequently to
incorporate new changes. They assist the inspection procedure but not a replacement for human code review
and knowledge.
The errors that are generally detected during the code inspections are listed below −
The variables are not initialized correctly before actually using them.
The constants have no proper names.
There is buffer overflow.
Exceptional Errors include all other error conditions which may appear in the software.