Peer reviews
Welcome to this microlearning session on peer reviews with eMagiz. In this microlearning, we will explore how peer reviews can enhance the quality of your integration solutions on the eMagiz platform. We will cover essential prerequisites, key concepts, and practical tips for running effective peer reviews. Whether you are new to peer reviews or looking to refine your process, this session will provide valuable insights to help you and your team achieve higher quality and consistency.
Should you have any questions, please contact academy@emagiz.com.
1. Prerequisites
- Basic knowledge of the eMagiz platform
2. Key concepts
This microlearning centers on peer-reviews.
- By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production.
3. Running peer reviews in eMagiz
Peer reviews is a well known and working concept with IT organization, and it can definetely applied in DevOps teams that have eMagiz as one of the technology pillars.
Key benefits of peer reviews:
- Improved quality of integrations
- Higher consistency
- Knowledge sharing
- Keeping standards for optimal maintenance
- Architecture challenge and verification
- Find alternative solutions
3.1 Who and when
Doing peer reviews increases the quality of the delivered work by the team. This means it is the whole team's responsibility to ensure peer reviews are performed. Following that logic, asking different individuals within your team for other peer reviews makes sense.
As described below, peer reviews should be conducted for every critical decision when building an integration solution via the eMagiz platform. See section 3.3 for a detailed list.
3.2 Considerations for reviewee
Here are some things to keep in mind when presenting the work to peer review.
- Quickly explain the story / task / background
- Quickly show the working result if applicable / practical
- Talk through the solution while showing the models / code
- Just trying to explain your work to someone else will help spot mistakes
- Don’t show every single detail but try to highlight the important parts and/or details you’re less sure about. This takes time and experience to get “right” and is different depending on the story, the reviewee, the reviewer, the project, etc.
- Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
3.3 Considerations for reviewer
Here are some things to keep in mind when peer reviewing the work .
- Ask questions
- How does this work?
- Why did you decide to …?
- Did you think about …?
- Spot (incorrect) assumptions
- Check application of best practices – see next slide
- Modelling / coding patterns
- Naming conventions
- Errors / warnings
- Notice non-standard / unusual / abnormal things
- Make sure this is documented, mainly for future changes. Annotations are very useful here.
3.3 Peer review items per ILM Phase
- Capture
- 100% filled
- Connection method clear
- Authentication method clear
- Definitions loaded
- Sizing impact understood and valid
- Design
- Check solution architecture validity
- Design 100% filled and clear
- CDM Root entity mapped
- Set as mapped – avoid line mapping
- Use annotation where possible
- Proper flow and system settings
- Create
- Validate routing
- Generic error response flows
- Check naming conventions flows, properties and XSD
- Split messages in on-ramp – not later
- Deploy
- Check properties
- Avoid too many different flow versions – max. 2
- Remove test packages that are deployed
- Manage
- All alerts mapped to Customer Support
- All messages can be explained
- Avoid code mappings
- Enable default alerts
- Architecture
- Deploy connector close to the source/target system
- Ensure ACCP and PROD are exact copies
- Cloud over on-premise
- No hard-coded variable – use properties
4. Key takeaways
- Peer reviews are essential in any DevOps team for improving the quality of your integration solutions by identifying and correcting defects early in the development process.
- Implement a structured approach to peer reviews by following the provided checklist for each Integration Lifecycle Management (ILM) phase. This will help maintain consistency and thoroughness in your reviews.
- Use the peer review process not only to catch errors but also to foster knowledge sharing and challenge architectural decisions. Adjust the peer review process as needed based on team feedback and evolving project requirements.
5. Suggested Additional Readings
You will find plenty background items available on the Internet. If you are interested in this topic within the eMagiz platform, please see the following link: