Hello people involved in chaos! and welcome to another post of analysis and design. I am happy to se you again after a long time. Today I let you know all you have to be aware to the subjet code review and dont die at the try.
When revisions of the code are introduced within the development cycle of a team, it is usually habitual her about certain concerns, suspicions and even misgivings arise. Why do code reviews? Who will do them? What will be revised? Are they really necessary? Beyond this, read the written code for other is good to improve the programmer and to write good code.
Well, but you ned to know what is code review, so lets see the concept of slashM:
Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, and fixing bugs during later stages of development or after programs are delivered to users.
Reviewers read the code line by line to check for:
- Flaws or potential flaws
- Consistency with the overall program design
- The quality of comments
- Adherence to coding standards.
Code review may be especially productive for identifying security vulnerabilities. Specialized application programs are available that can help with this process. Automated code reviewing facilitates systematic testing of source code for potential trouble such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review is also commonly done to test the quality of patches.
The ultimate goal of a code review should be to determine what is being done well to continue doing it, and what can be improved.
SmartBear give us some good practices regarding code revision, let’s squeeze it!!!
- Review fewer than 400 lines of code at a time
a study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.
- Take your time. Inspection rates should under 500 LOC per hour
Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review.
- Do not review for more than 60 minutes at a time
When people engage in any activity requiring concentrated effort over a period of time, performance starts dropping off after about 60 minutes.
- Set goals and capture metrics
Easy, we are not dumies you have to keep trsck of your research.
- Establish a process for fixing defects found
Even after optimizing code review processes by time-boxing reviews, limiting LOC reviewed per hour and naming key metrics for your team, there´s still a key review step missing.
AND THE MOST IMPORTANT THING!!
Foster a positive code review culture
Do you want to be a pro? check it out!
References:
Code Review: Todo lo que debes saber
https://searchsoftwarequality.techtarget.com/definition/code-review
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
Credits at the outstanding image
Carol F
image from Pexels
Understated Chaos 