A note on Peer Review

Peer review is generally an evaluation of a software product’s technical content and quality control practices, by allowing teams to review their development artifacts prior and frequently. It is a critical and crucial step in software development as it adds tangible value to software and ensures the integrity of the end goal. The benefits of code review are widely accepted as a quality improvement and control strategy. The development community now understands the influence of code review on overall software quality and that it has the ability to identify and correct errors before the code is passed over to QA for testing.

Performing Peer Review

It is imperative that the code in every Mendix project should be Peer-reviewed within the organization. This should be done by a direct peer (if applicable) and in the case of a single team member, a member of the core team should be asked to do an application review. The end goal is to deliver better quality applications by checking the code to the convention guidelines. It creates an environment where the team members can collaborate and share knowledge which often leads to saved time and reduced risks.

Listing Peer review

  • Is it easy to read? Does it satisfy KIS (Keep It Simple)?
  • Does the naming of flows and folders follow logical structure?
  • Are all the access permissions set correctly?
  • Was there any code reuse or code duplication?
  • How is the error handling in a flow covered and tested?
  • Are there any performance risks?
  • Was logging and error handling done in a correct way?
  • Do you understand the impact of your change on the existing app (regression)?

Practical checklist

During development, each story goes through a set of phases.

  • 1. Implemented locally by the developer
  • 2. Tested locally by the developer
  • 3. Committed to the team server
  • 4. Labelled as ‘Ready for Peer Review’

The peer should then check the story on both technical and functional levels:

Technical:

  • Have Pages and microflows been given the correct rights?
  • Were Error handling and validation implemented correctly?
  • Adherence of microflow to basic guidelines (maximum of X actions per flow, readable, etc.)
  • Consideration of app performance (Are there nested loops? Are there commits in a loop, etc.)
  • Has the micro flow been implemented in a technically correct way?
  • Alignment with basic conventions.
  • Proper security setup

Functional:

  • Were pages and microflows placed in the right folders?
  • Were Pages and microflows given clear names?
  • Has the change been implemented in a logical, user-friendly, and correct manner?
  • Does the micro flow work as described in the story?
  • Does the result meet the expectations defined as the acceptance criteria?

Acceptance Criteria refers to a set of predefined requirements that must be met to mark a user story as completed. Also sometimes called the “definition of done”.

NOT part of the peer review: The peer reviewer should not make changes to the model/pages/micro flows, because:

  • The original developer may look at the implementation in a different way
  • The original developer perhaps not be able to learn from their mistakes
  • The original developer will not know what has happened to the original implementation.

This blog was published in Mendix Community on July 3rd, 2022 - https://medium.com/mendix/the-importance-of-peer-review-in-mendix-70525da1459b