Review Code

(Activity) for Tier: Sprint

PURPOSE

Code review is a critical examination of any computer source code library, repository, branch, component, project, database, et al. The primary purpose of code review is to locate and address mistakes, defects, and/or inconsistencies which were potentially overlooked in initial development, unit testing, or automated testing. The cumulative result of regularly conducting well-disciplined code reviews is an ever-increasing quality of the software solution, and also offers additional benefits including:

  • Continuous definition and refinement of team engineering guidelines and norms
  • Improved developers’ skills and cross-training of disciplines, languages, tools, and techniques
  • Code refactoring, reuse, and performance tuning
  • Pro-active management of code health and remediation of technical debt

Code reviews are conducted using Git and Azure DevOps Pull Requests but may include a variety of supporting methods such as paired and group programming sessions.

WHEN

The code branch contains the desired functionality.

PARTICIPATING ROLES

INPUTS

ENTRY CRITERIA

  • Code for User Story(s) or Bug is complete.
  • Unit tests for the code area are complete.
  • There are no merge conflicts between the source and target branch.

SUB-ACTIVITIES

  1. Prepare for Code Review

    • Gain early feedback for large or high-risk changes

      • Create a draft pull request and add reviewers who are familiar with the code area.
      • Ensure the Lead Developer and Solution Architect are included as applicable.
      • Publish the pull request once the reviewers buy-in.

    • Create a Pull Request

      • Ensure the source branch is free of merge conflicts with the target.
      • Select the source branch and verify the correct target for the pull request.
      • Provide a useful description of the changes.
      • Ensure the pull request adheres to the team’s defined template. Templates are used to codify company and team policy.
      • Ensure a User Story or Bug is linked. Ideally these are already linked when the work began.
      • Add reviewers and tag the pull request per the team’s procedure.

  2. Review the Code

    • Review the Checklist

      • Ensure all required items are checked.
      • Examine the changes for evidence that the checklist has been satisfied.

    • Review Changes

      • Ensure the Following:

        • The code is relevant to the task for which it is written. There shouldn’t be any code changes allowed that do not address the intended functionality, with the exception of refactoring to improve design of existing code.
        • The code compiles without errors.
        • The code adheres to or evolves the architecture.
        • The code is examined for security vulnerabilities.
        • External interfaces match their specifications.
        • Any additional criteria specified in the team’s procedure.
        • Provide comments on code that doesn’t meet the above criteria.

    • Review tests

      • Unit tests have been changed according to code changes.
      • Test code coverage results cover changed code.
      • Code coverage percentage with the updated code is greater than or equal to the code coverage percentage before the code was updated.
      • A reasonable justification has been given to allow the review to be approved without necessary tests.
      • Provide comments on insufficient or incorrect tests.

  3. Provide and Address Feedback

    • Reviewer:

      • Provide suggestion comments when the code may optionally benefit from a change. Make it clear that the comment is an optional suggestion.
      • Provide comments on blocking concerns when the code quality is in question, or a bug is found. Make it clear that the comment blocks approval.

    • Reviewee:

      • Choose whether or not to include optional suggestions and resolve the feedback.
      • Respond or address blocking concerns. Ensure you have buy-in from reviewers before resolving their feedback.

  4. Vote on Pull Request

    • Approve, Reject, or Wait for Author

      • Approve pull requests that meet expectations per the process and team’s procedures.
      • Reject inappropriate pull requests that should not be merged such as out of scope or duplicative work.
      • Wait for author on pull requests pending fixes or blocking comments.

  5. Tag Pull Request

    • Tag Pull Request with categories of issues identified during the review

      • See Pull Request for standard tags.

        Note

        Any additional tags should be defined in team procedures and the pull request template.

OUTPUTS

EXIT CRITERIA

  • Required reviewers have approved or rejected.
  • Target branch policies have all been satisfied.
  • The pull request does not have any merge conflicts.
  • Reviewers have adorned Pull Request with tags based on feedback provided.

NEXT ACTIVITY