What are the best ways to ensure code review focuses on quality and maintainability?

Usually each developer has there own style of coding some like tab spacing some like normal spacing so it's becomes essential to have a defined structure to be applicable for everyone. So it becomes necessary to have checks using husky linked with structured commit message which helps organized release output. Along with this CI becomes much more essential and important to have checks applied to all the PRs keep checks such as sonar, test coverage checks etc etc. This defines to have few predefined structure which helps maintain the code quality with optimal level.

Stop with useless comments or at least tag them with nit: Anything a linter, sonar or prettify can catch should not be in your comments, instead make the linter more strict to make the engineers follow the standards As a code reviewer our job is to identify case where the code and their test cases would break and fail. I would break it in tiers of feedback / catches Tier 1: Core design issues / case misses Tier 2: Core coding standard pattern miss Tier 2.5: Core testing scenario miss / e2e tests miss Tier 3: coding bugs that unit tests didn’t catch Tier 4: nits and styling improvements As a good code reviewer you are not only the gate you are also the care taker and evangelist to help your team learn practices and yourself to learn

* Avoid nitpicking and focus on substantive issues during code reviews. * Only comment if necessary; pushing "Approve" button is sufficient, there's no need for redundant comments like "LGTM". * Provide reasons for suggested changes instead of just stating what needs to be fixed. This enhances learning for multiple individuals. * If a code review is too lengthy, request smaller and more logical reviews. Lengthy reviews can diminish attention and result in overlooking critical issues. * Maintain a constructive and non-aggressive tone in your comments. Remember that not everyone may have the same level of knowledge, so share insights without being confrontational.

Standards should be codified using popular linting frameworks. Linter should run before a checking using hooks and also in CI pipelines, code should be reviewed only after the linter has succeeded.

To ensure that code reviews focus on quality and maintainability, consider the following key strategies: Establish Coding Standards: Define and communicate coding standards to maintain consistency and readability. Automated Code Analysis Tools: Utilize tools that automatically analyze code for issues, adherence to standards, and potential improvements. Focus on Readability and Documentation: Encourage clear and well-documented code to enhance understandability and future maintainability. Regular Training Sessions: Conduct periodic training sessions to keep the development team updated on best practices and emerging technologies.

Create a check list that is displayed when a code review is created. Git hub PR templates is a good example of how to achieve this. Review process should be integrated with the source control system like git or svn. One should be able to track every line of code back to a review, so the decisions made during the review are available.

Leverage checklists and templates in code reviews for a focused evaluation. Checklists address errors and best practices, while templates provide a structured framework for actionable feedback. These tools enhance consistency, efficiency, and continuous improvement in the code review process.

Checklists and templates ensure quality, consistency, and efficiency in software development. They prevent errors, save time, and foster collaboration by establishing shared guidelines and scalable practices. Checklists help adhere to coding standards and handle error cases, while templates offer predefined structures for common tasks. They also serve as learning aids during onboarding and can be adapted over time, consolidating proven approaches and facilitating continuous improvement. In summary, checklists and templates create a structured and efficient framework, contributing to the overall quality and maintainability of the code base.

Code review comments should be in third person. Avoid making personal comments. Remember that is a comment about the code and not about the person who wrote the code. Any stylistic discussions can be taken outside the review. Long threads of discussions on topics that are not very relevant tend to be a barrier to communication. If there is disagreement over something, create a follow up item to fix the problem and move ahead with review.

Code reviews are like team huddles in sports: everyone's input is crucial, and the goal is collective improvement. Good communication is key. Treat it like a friendly, collaborative discussion. Clearly define what you're looking for in the review, akin to outlining a game plan. When giving feedback, opt for words that encourage and guide, much like a coach rather than a judge. Foster open conversations; often, great ideas sprout from these exchanges. Be specific with your suggestions, offering clear, actionable advice, just as you would in a team strategy session. Remember, code reviews are learning moments for all, a chance to enhance both quality and maintainability of the code through teamwork and shared insights.

Effective communication is vital in code reviews to prevent misunderstandings and conflicts. Use respectful language, clearly communicate the review's purpose, scope, and expectations, and provide specific, objective, and evidence-based feedback. Avoid vague or personal comments. Acknowledge positive aspects, encouraging questions and discussions. Timely and clear communication fosters a constructive review process, minimizing delays and enhancing overall collaboration.

Effective communication is crucial for successful code reviews. Clearly express expectations, offer specific feedback, and encourage open dialogue. Acknowledge positive aspects, avoid ambiguity, and create a constructive environment for efficient collaboration.

Managing large and intricate code changes during reviews poses significant challenges, leading to potential overwhelm, tedium, and increased chances of errors. A recommended approach is to tackle code review in smaller, logical batches, breaking down changes into manageable units. Regular, frequent reviews prevent the accumulation of a large volume of code, aiding in sustained attention, concentration, and motivation. This not only streamlines the review process but also mitigates the risks of conflicts, bugs, and the accrual of technical debt.

Ensure that a code change addresses a well defined and single problem. Use feature flags to disable code that is not yet ready. This will ensure that all the code that is needed for a feature is not in one PR. Writing test cases helps to have a modular design and in my experience it has helped me to split up the tasks so that each task is manageable and testable. Set a reasonable limit to number of lines modified so developer is not caught unaware. Exceptions to this rule will be any files that are auto generated.

Reviewing small, logical code batches is crucial. Break down changes into manageable units to maintain focus, reduce errors, and prevent technical debt. Frequent reviews ensure efficiency and mitigate conflicts and bugs.

Embrace collaboration in code review. Seek diverse perspectives from various reviewers, considering feedback openly. Engage with the code author, explaining your reasoning. This approach enhances code quality, maintainsability, and fosters trust and innovation in the development culture.

As with experience, we have different perspectives of the code we write and so it's always important to have different people making the effort to review the code it helps the person who is reviewing the code get some new ideas of how to write code and also gets the knowledge of how everything is getting built. Seeking multiple perspectives for code review refines the process of buggy code to be deployed and has optimal solutions for everyone to learn new things.

Skip doing any of these checks manually and automate as much of the quality process as possible. Make the merge process as frictionless as possible by catching errors before they’re even committed. Code reviews should focus on functional correctness; no one should ever have to do a review code like they’re reviewing someone’s homework for spelling errors.

Automating some tasks during code review with the help of tools can boost efficiency. Using automated tools makes the review process faster by fitting right into the development workflow. But don't rely too much on automation as it's essential to have a human check the code for contextual nuances that automated tools can't detect. When we combine automation and human expertise, we get an optimized code review process that creates a more thorough and efficient assessment of code quality.

Some of the ways to ensure code reviews maintain quality and maintainability are : 1. If a mutually/organisation wide code review template incorporating best practises is used for such reviews (like a checklist). 2. We could use tools like static code analyzer (SonarcQube, Checkstyle etc..) 3. Incorporate the principles of maintainability --> standardisation, modularisation, fault isolation, inter-changeability etc.. 4. Also look at aspects like data structures and memory management in the code. 5. Finally, quality gates to be used during the CI/CD process.

Many teams ensure that code cannot be delivered unless there is a code review, while this is fine and necessary. There needs to be periodic code reviews looking at the code as a whole. Typically a group of 2-3 developers should get together and look a feature/function and see if there is any scope for improvement or de duplication. If something is found than tech debt issues need to be created and worked upon.

Article très bien fait, mais je n'ai pas vu mentionné la revue en pair. Parce que toutes les revues ne sont pas faites en présence du valideur et du développeur.