You're in charge of code reviews for a project. How do you ensure they are thorough and efficient?

1. Maintain a neutral tone: It’s common for PR authors to perceive review comments negatively and become defensive. Strive to keep your tone neutral to avoid unnecessary conflicts. 2. Focus on the code, not the person: Address the issues in the code rather than critiquing the individual. Remember, the goal is to improve code quality, and focusing on this shared objective can help maintain a collaborative atmosphere. 3. Support comments with evidence: Use doc links, references, and examples to back up your comments. This enhances the credibility of your feedback and provides a clear rationale. 4. Be specific: Indicate whether a comment is a blocker or a nitpick. This helps streamline the review process and prioritizes critical changes.

To ensure code reviews are thorough and efficient, I implemented a structured checklist, set clear guidelines, and use automated tools for initial checks. Additionally, I schedule regular review sessions and encourage constructive feedback to maintain quality and consistency.

*What makes a good code?* It does what it supposed to do, and has good performance, readable and maintainable. So code review must encompass all aspects in general: - whether it complies to high level design principles (e.g. which modules should take the responsibility of particular aspect of functionality, or whether API contracts are clean) - whether it is free from coupling, - whether it will perform well in larger scale - is there an adequate code reuse instead of duplication of code - did we ensure new code remains readable - did we added or extended the tests - did we ensure no hard wired configs The word code review sometimes limits what people think of it. But in reality, it should be a full review of the entire software itself.

First, you need to determine why you should review the code. Then, you should determine how to measure that according to the standarts. The main thing is that people code in different ways, but it should be clean, efficient and maintainable.

Developing a code review strategy in software development involves several key steps. Start by defining clear objectives for the code review process, such as improving code quality, sharing knowledge, and ensuring adherence to coding standards. Establish guidelines for conducting reviews, including the roles and responsibilities of reviewers and authors, preferred tools for reviewing code, and expected turnaround times. Encourage a constructive feedback culture where critiques are focused on improving the code rather than criticizing the developer. Implement regular checkpoints, such as before merging code into the main branch, and consider involving team members with relevant expertise for specialized reviews.

Code review should be an overall workflow- not a last step ceremony. 1. Bring out any assumptions upfront 2. The developer should ideally be aligned to seniors in terms of the approach or design that should be appropriate 3. Identify what areas of regression will have an impact 4. Code step by step to validate it works as expected 5. Ensure exceptions, and boundary cases are handled well, 6. Once the development is fully compliant to design and achieves the required, then we can focus on modularity and code readability One of the trap of poor code review process is to keep gold plating in terms of code readability but ignore critical design evolution aspect. Avoid this at all costs.

I'd start with two simple (but not always easy) guidelines: For reviewers: Write clear, actionable, unambiguous comments and distinguish between questions, to-dos, and nice-to-haves. For reviewees: Give enough context and write short and focused Pull or Merge Requests that any reviewer can finish in less than 30 minutes without too much discussion.

Use code reviews as an opportunity for discussion and learning. Encourage open dialogue about design decisions and alternatives.Address any disagreements or conflicts quickly and constructively, focusing on finding the best solution for the project.

This might be an unconventional advice - but expecting senior devs trying to "teach" junior devs as part of the code review process will bloat the whole process. The specific feedback itself should be sufficient for junior to improve; and the manager should take a note if there is a repeated help someone needs. A good culture of software engineers is where everyone realises they got to keep learning, and not have explicit sessions and discussions to make the understand basics. Second, code reviews are really not the place for debates. It may spark the debate in some cases, but they are beyond this. Making code review process, simple and iterative and free from bureaucratic norms is critical to being agile.

Code review should be a moment of discussion to ensure the delivery of functionality and quality! We should not focus on finding and highlighting people's mistakes but rather on discussing how we can generally improve the company's coding practices.

Avoid the trap of code review as a "last step"! If we spot design changes, efficiency issues, or any major structural issues, the entire effort will go for a toss. The simpler soution is as follows: - Ensure that devs have directional understanding from the beginning - Implement in small steps, get things tested and provide early feedback. Feedback from testing (unit as well as integration testing) is equally important - Maintain the code in a good condition through out the development, avoid the temptation to "clean it later" - Maintain business domain language and naming and structuring of the code from the beginning

Stop using "pushy" questions to ask for changes. You know, those questions that only hint a request for a code change. While working on a remote team, it happened more than once that I had to reach out to reviewers to ask them to clarify their intentions behind "pushy" questions. But some reviewers were on the other side of the world. All interactions took about ~24 hours between my initial message and their response. It was frustrating and time-consuming. Instead of asking "pushy" questions, leave actionable and unambiguous comments that distinguish between questions, to-dos, and nice-to-haves. Ah! And always leave a suggestion or example in your comments.

When it comes to the organization level, there should be pre-defined rules and guidelines for coding. For example, how to make understandable comments, how to structure folders, and how to define functions. People may code differently, but the quality can vary. With pre-defined coding guidelines, developers can follow a consistent approach, reducing the time needed for code reviews. However, code reviews are still valuable as they help everyone learn and avoid mistakes. Overall, pre-defined guidelines help maintain the codebase, especially in large projects.

One tip to improve code reviews: use short PRs. PRs everyone could review in 10 or 15 minutes without too much discussion. As a reviewer, I wouldn’t mind reviewing multiple short PR’s in a working session than reviewing one single long PR that exhausts all my mental energy.