Peer reviews - eMagiz

{{container}}{{container layoutStyle="columns"}}(((

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.

4

5

Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].

6

7

== 1. Prerequisites ==

8

9

* Basic knowledge of the eMagiz platform

10

11

== 2. Key concepts ==

12

13

By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production.

14

15

== 3. Running peer reviews in eMagiz ==

16

17

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.

18

19

[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]

20

21

Key benefits of peer reviews:

22

23

* Improved quality of integrations

24

* Higher consistency

25

* Knowledge sharing

26

* Keeping standards for optimal maintenance

27

* Architecture challenge and verification

28

* Find alternative solutions

29

30

=== 3.1 Who and when ===

31

32

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.

33

34

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.

35

36

=== 3.2 Considerations for reviewee ===

37

38

Here are some things to keep in mind when presenting the work to peer review.

39

40

* Quickly explain the story / task / background

41

* Quickly show the working result if applicable / practical

42

* Talk through the solution while showing the models / code

43

** Just trying to explain your work to someone else will help spot mistakes

44

** 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.

45

* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.

46

47

=== 3.3 Considerations for reviewer ===

48

49

Here are some things to keep in mind when peer reviewing the work .

50

51

* Ask questions

52

** How does this work?

53

** Why did you decide to …?

54

** Did you think about …?

55

* Spot (incorrect) assumptions

56

* Check application of best practices – see next slide

57

** Modelling / coding patterns

58

** Naming conventions

59

** Errors / warnings

60

* Notice non-standard / unusual / abnormal things

61

** Make sure this is documented, mainly for future changes. Annotations are very useful here.

62

63

=== 3.3 Peer review items per ILM Phase ===

* Capture

** 100% filled

** Connection method clear

68

** Authentication method clear

69

** Definitions loaded

70

** Sizing impact understood and valid

71

* Design

72

** Check solution architecture validity

73

** Design 100% filled and clear

74

** CDM Root entity mapped

75

** Set as mapped – avoid line mapping

76

** Use annotation where possible

77

** Proper flow and system settings

78

* Create

79

** Validate routing

80

** Generic error response flows

81

** Check naming conventions flows, properties and XSD

82

** Split messages in on-ramp – not later

83

* Deploy

84

** Check properties

85

** Avoid too many different flow versions – max. 2

86

** Remove test packages that are deployed

87

* Manage

88

** All alerts mapped to Customer Support

89

** All messages can be explained

90

** Avoid code mappings

91

** Enable default alerts

92

* Architecture

93

** Deploy connector close to the source/target system

94

** Ensure ACCP and PROD are exact copies

95

** Cloud over on-premise

96

** No hard-coded variable – use properties

97

98

== 4. Key takeaways ==

99

100

Peer reviews are instrumental in any DevOps team. Use the provided list as your team's peer review starting point and tune as you go along.

101

102

== 5. Suggested Additional Readings ==

103

104

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:

105

106

* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]

107

** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]

108

*** [[The five phases of eMagiz (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-the-five-phases-of-emagiz||target="blank"]]

109

* [[Peer Review (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&l_space_facet=10&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=%22peer+review%22||target="blank"]]

110

)))((({{toc/}}))){{/container}}{{/container}}

Wiki source code of Peer reviews

Navigation