I’m sure we’ve had instances where we felt we’ve written the next best thing… just to have your lead break it down on the other side of the call, and show you a simpler way you could have gone about it. Moments like this are a pain in the ass.
The aim of the collaboration is to solve problems, while we all have different approaches to problem-solving some approaches need to be checked and inspected by either a better-experienced colleague or a peer that could help refactor. Half of the time we want to ship fast, which is understandable but we later realise the due process has not to be taken and will cost a lot more to refactor and review.
Code review can be described as working with a fellow developer, colleague or better-experienced developer to check the code to correct the flow, process and sometimes syntax.
The Unending loop of Technical debt:
Technical debt is the cost or amount of time used to reiterate an incomplete solution or limited solution. In most cases, we ship the fastest solution but we could also take a step back and review the code and use cases for the issue.
In other cases, there would be a different approach to solving the said issue.
Code review in open source projects is critical, firstly because there are lots of contributors and what goes to the code base is really important. Poorly reviewed code could crash important services and cost the users many resources. First-time issues should also have much attention, they might have a low contribution but a lack of familiarity with the code base could ruin the previous work that’s been done by previous contributors.
What to look out for in Peer code review
- Functionality
- Complexity
- Separation of concerns
- Depreciated syntaxes
- Styling
- Context
- Comments
- Reusability
- Each line of code
- Enforce best practices
Tips for reviewing a teammate’s code or Open source Contribution
- Explain the problem explicitly
- Be positive and kind
- Anybody’s code can be reviewed regardless of how Senior the person is
- Give everyone a chance to learn concepts and grow
- Automate some processes
- Enforce testing before building
- Tabs > Space
Doing this due diligence will save your team a lot of time, and the negligence will also cost a lot of time.
One of the most common tools for code review is Github pull request comment section on Github, when PR is sent every commit and line can be commented on using this section of Github.
After every code review, the reviewer and the reviewed should make sure there’s proper functionality, UI changes are appropriate, the code is written with the best practices and the code passes all the set tests. In the case where the task is not successfully done the review should return and fix the issues then schedule another code review.
Top comments (0)