When you already know the main reasons to refactor your code, there are some best practices of the code reviews you should take into account as well!
We perform code reviews (CRs) in order to improve code quality and benefit from positive effects on team and company culture. For example:
- Committers are motivated by the notion of a set of reviewers who will look over the change request: the committer tends to clean up loose ends, consolidate TODOs, and generally improve the commit.
- Sharing knowledge helps development teams in several ways:
– A CR explicitly communicates added/altered/removed functionality to team members who can subsequently build on the work done.
– The committer may use a technique or algorithm that reviewers can learn from.
– Reviewers may possess knowledge about programming techniques or the code base that can help improve or consolidate the change;
– Positive interaction and communication strengthen social bonds between team members.
- Consistency in a code base makes code easier to read and understand, helps prevent bugs, and facilitates collaboration between regular and migratory developer species.
- Legibility of code fragments is hard to judge for the author whose brainchild it is and easy to judge for a reviewer who does not have the full context.
- Accidental errors (e.g., typos) as well as structural errors (e.g., dead code, logic or algorithm bugs, performance or architecture concerns) are often much easier to spot for critical reviewers.
- Compliance and regulatory environments often demand reviews.
Part of the purpose of the code review is to improve the author’s change request; consequently, don’t be offended by your reviewer’s suggestions and take them seriously even if you don’t agree. Respond to every comment, even if it’s only a simple “ACK” or “done.”
More code review examples are here.
As a bonus, here you can read about CodePen modern analogs to ease your development.