7 steps for code reviewing via C3.

Code reviewing is a fun activity within the team. Similar to taking a chilled beer with colleagues, the code review process should be taken as an opportunity for you and your team members to grow by sharing each other's knowledge. Also, the trust within the team grows, the work everyone does at the table gets transparent. And, of course, it's for the best of the project. No matter how much extra time it consumes back n forth, it's all worth it in the end. The stability of the functional and non-functional requirements of the project is priceless in nature.

Foster a code-review culture within the team...

We all must insist on a review of a pull request, or get a review on our PR before merging (if your branches aren't protected, rare!)

If your organization or team doesn't have a code review culture, it doesn't need an announcement or to wait for the rules to be defined. Just before merging your code to your code versioning tool, call up one of your teammates to test and review the code for the 'XYZ' feature. Doing this every time and encouraging others in the team to do so, slowly you will foster a code reviewing culture and you can keep your stable branches separate and protected, even start following proper git branching strategies.

It shouldn't be like only the senior developers reviewing all the code. It must be an equivalent exercise of the team. This makes the skillset of the team members even, and knowledge about the project balanced within the team. This reduces the dependency of one developer on the one main feature, the reviewer also gets knowledge and understanding of that part of the code. Thus, helps in resolving the bug fixes quicker in long run, or even adding more features on top of it gets easier.

Again, code reviewing should be an enjoyable activity and must increase the contribution, collaboration, and communication within the team.

How to begin reviewing a pull request?

• The first step by the reviewer should be to understand the functional requirements and test the branch if the business requirements are fulfilled and the code works and doesn't fail in most of the test cases which come to reviewers mind, the rest is on the testing team.

What to look for in the code?

• The second step is to rush to the code and understand the logic done by the author of the PR.
• The third step is to think about a better way of doing the same. If you couldn't find a better way. Measure the worst-case complexity of the code, and see if there are any optimizations that could be done at different places. In simple terms work on non-functional requirements i.e. reducing the latency, database queries, indexing, throughputs, any asynchronous jobs. Profiling the code, reducing the memory consumptions, removing the unnecessary objects from the memory, and reusing the ones which are already present and necessary in memory.
• The fourth step is to check for semantic errors, the variable names are properly used, code is following the industrial standard practices, easily readable and understandable, most commonly PEP8 for python, automatic linters are passed, unit tests are created for the newly introduced features. Docstrings are in place which explains the functionality and parameters used within the Class, Definition, Method, Function, Property, etc. Following the good old SOLID principles, reusing the other parts of projects and not duplicating any code for the same purposes i.e. utility functions.

How should a review be submitted?

• The fifth step, Its time to make comments in the code, the comments must be soft in a tone not authoritative (remember its a fun knowledge sharing activity), and you may use notions like ?? a rocket for mandatory changes, and ?? an eye for optional changes if something doesn't impact much of the system but looks good or nice to have. There must be a well-defined reason for something to be a rocket and must be conveyed softly via comment.

How to resolve arguments between an author and reviewer?

• In the sixth step, if there are conflicts on the requested changes, schedule a peer programming session, I guarantee both the reviewer and author learn a lot with this. There will be a well-explained version of everything on the table. Finally, both of them have to weigh the pros and cons and settle in between something.

Again, code reviewing is an enjoyable activity and must increase the contribution, collaboration, and communication within the team. C3

When and how to merge the latest changes to the main branch?

• The final seventh step, resolve the PRs quickly don't let the branch stale, it increases the conflicts to resolve with others. I'd encourage the pull request must not go over 600-1k LOCs. For faster processing you may create your own checklist with GitHub actions workflow to work on every PR like Linters to be passed, Unit tests to be passed, etc.

Finally, In my team, we prefer to squash and merge every PR into one commit. Though it doesn't add actual contributions to your profile, and it doesn't go all green especially in private repositories.

But, make sure the commit messages are sensible enough in either of the cases squash and merge or rebase and merge.