Code Review

Code Review is a sensitive matter. It introduces the code you wrote to the eyes of another person, who has their own expectations, perceptions, and demands. How should this process be managed? How to enter it calmly and emerge unharmed.

First, why would we do code review?

Maintaining code quality is essential. Every organization strives to have a well-written codebase. Unclear code creates a cognitive burden for anyone who reads it in the future. Coders should be aware that they are creating technical debt for future maintainers, including themselves.

I have 5 pieces of advice for both programmers and reviewer

For programmers:

1) Approach code reviews with a learning mindset. If you receive feedback you disagree with, remember it's not personal. The reviewer might be having trouble understanding the code or might not be the best at expressing their suggestions in a diplomatic way. Code reviews are text-based, so emotions don't always come through clearly.

?

2) Write clean and readable code. Strive for code that's easy to understand without excessive effort. This includes using clear structure, logical naming conventions for classes, variables, and functions, and dividing code into well-defined modules. Code review shouldn't only just catch bugs. Automated tests are designed to catch bugs. Make your code correct and according to the standard, no typos no silly mistakes so that the reviewer will not be overwhelmed and start giving a lot of comments and miss the main content of the code.

?

?3) Prepare the structure of what you are sending. Break down your changes into logical units that meet the specific requirements. Aim for commits of a reasonable size that are easy for reviewers to understand. You don't want commits to be too small and lack context, but also avoid massive changes that are difficult to review. Rule of thumb: first move, then change. In case you need to refactor and change, make it in two separate commits.

?

4) Give context. Provide clear context in your code review description. Briefly explain the task, request, and associated Jira ticket (or equivalent tracking system). This helps reviewers understand the purpose of the code changes. A link to the results of tests will give a great confidence to the reviewer that the code has been tested and is correct. A screenshot of the tests done will also help. Consider including unit tests within your commit whenever possible.

?

5) If you have many questions, don’t hesitate to use RFC. Request For Comment, you can ask for comments before you send the code to review. It is ok to do this as long as the reviewer has accepted your request.

?For reviewers:

1)?Be kind. Be clear and straightforward. Use code reviews as a learning opportunity for everyone involved. The goal is to help programmers improve their skills. Remember code review, by definition it is a complicated situation where you need to judge something. Focus on constructive feedback instead of judgment. This is not code you would write. Sometimes even the code we write becomes bad for us if we read it after a week.

?

2) Reviewer needs to verify code quality and maintainability of an organization's codebase. This is his duty. Is code thread safe? Is code aligned to idiomatic programming? Whether we like it or not, we need to follow the rules. For example, in Java, in case we work with streams, we can’t allow code with loops. You need to align to the standards. In case we write comprehensions in Python, we keep it that way.

??

3) For reviewer (and for me as a person), If the code works, aligned to the standards, has logical entities, tests have passed successfully, and I DO NOT like the code – I will approve the review. ?Code review requires some kind of maturity. ?There are always alternative ways to reach your goal. You sometimes need to let go because it is not personal, and it is not about egos we talk about.

?

4)?Code review should be asynchronous. I am against synchronous or team review. Team code review can be very harmful. ?Asynchronous code review should be no later than 3-4 days, maximum a week. Other than this, we might lose it. In case the commits were huge, there are lots of comments and replies and comments on replies, this needs to be moved into synchronous. Don’t waste your time on chatting. Just sit together and talk.

?

?5)?Remember, many times programmers copy paste an old code to generate a new code. This is alright. This is acceptable, but keep in mind, by ensuring the current code is well-written and functions correctly, you're helping to build a strong foundation for future projects. Incorrect code now might contaminate the future version of this code and perpetuate these errors. It is your responsibility as a reviewer to maintain a high standard of code quality.