Skip to Content

Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 22.7
edited by Danniar Firdausy
on 2024/09/18 14:40
Change comment: There is no comment for this version
To version 13.1
edited by eMagiz
on 2022/05/17 09:10
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,0 @@
1 -Peer reviews
Parent
... ... @@ -1,1 +1,0 @@
1 -WebHome
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.dfirdausy
1 +XWiki.marijn
Default language
... ... @@ -1,1 +1,0 @@
1 -en
Content
... ... @@ -1,9 +1,20 @@
1 -{{container}}{{container layoutStyle="columns"}}(((
1 +{{html wiki="true"}}
2 +<div class="ez-academy">
3 + <div class="ez-academy_body">
2 2  
3 -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.
5 +<div class="doc">
4 4  
5 -Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
6 6  
8 +
9 += Running peer reviews inside eMagiz DevOps team =
10 +
11 +In this microlearning, we will take a look at peer reviews for eMagiz.
12 +
13 +Should you have any questions, please contact academy@emagiz.com.
14 +
15 +* Last update: April 22nd, 2021
16 +* Required reading time: 8 minutes
17 +
7 7  == 1. Prerequisites ==
8 8  
9 9  * Basic knowledge of the eMagiz platform
... ... @@ -10,17 +10,12 @@
10 10  
11 11  == 2. Key concepts ==
12 12  
13 -This microlearning centers on peer-reviews.
14 -* By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production.
24 +Peer reviews are defined as follows: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. Its 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. In tbe context of eMagiz, peer reviews are done usually after the Create phase.
15 15  
16 -== 3. Running peer reviews in eMagiz ==
26 +<p align="center">[[image:intermediate-devops-perspectives-peerreview-1.png||]]</p>
17 17  
18 -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.
28 +Key benefits of peer reviews
19 19  
20 -[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
21 -
22 -Key benefits of peer reviews:
23 -
24 24  * Improved quality of integrations
25 25  * Higher consistency
26 26  * Knowledge sharing
... ... @@ -28,13 +28,11 @@
28 28  * Architecture challenge and verification
29 29  * Find alternative solutions
30 30  
31 -=== 3.1 Who and when ===
32 32  
33 -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.
34 34  
35 -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.
39 +== 3. Running peer reviews in eMagiz ==
36 36  
37 -=== 3.2 Considerations for reviewee ===
41 +=== 3.1 Considerations for reviewee ===
38 38  
39 39  Here are some things to keep in mind when presenting the work to peer review.
40 40  
... ... @@ -41,71 +41,84 @@
41 41  * Quickly explain the story / task / background
42 42  * Quickly show the working result if applicable / practical
43 43  * Talk through the solution while showing the models / code
44 - ** Just trying to explain your work to someone else will help spot mistakes
45 - ** 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.
48 + * Just trying to explain your work to someone else will help spot mistakes
49 + * 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.
46 46  * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
47 47  
48 -=== 3.3 Considerations for reviewer ===
52 +=== 3.2 Considerations for reviewer ===
49 49  
50 50  Here are some things to keep in mind when peer reviewing the work .
51 51  
52 52  * Ask questions
53 - ** How does this work?
54 - ** Why did you decide to …?
55 - ** Did you think about …?
57 + * How does this work?
58 + * Why did you decide to …?
59 + * Did you think about …?
56 56  * Spot (incorrect) assumptions
57 57  * Check application of best practices – see next slide
58 - ** Modelling / coding patterns
59 - ** Naming conventions
60 - ** Errors / warnings
62 + * Modelling / coding patterns
63 + * Naming conventions
64 + * Errors / warnings
61 61  * Notice non-standard / unusual / abnormal things
62 - ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
66 + * Make sure this is documented, mainly for future changes. Annotations are very useful here.
63 63  
64 64  === 3.3 Peer review items per ILM Phase ===
65 65  
66 66  * Capture
67 - ** 100% filled
68 - ** Connection method clear
69 - ** Authentication method clear
70 - ** Definitions loaded
71 - ** Sizing impact understood and valid
71 + * 100% filled
72 + * Connection method clear
73 + * Authentication method clear
74 + * Definitions loaded
75 + * Sizing impact understood and valid
72 72  * Design
73 - ** Check solution architecture validity
74 - ** Design 100% filled and clear
75 - ** CDM Root entity mapped
76 - ** Set as mapped – avoid line mapping
77 - ** Use annotation where possible
78 - ** Proper flow and system settings
77 + * Check solution architecture validity
78 + * Design 100% filled and clear
79 + * CDM Root entity mapped
80 + * Set as mapped – avoid line mapping
81 + * Use annotation where possible
82 + * Proper flow and system settings
79 79  * Create
80 - ** Validate routing
81 - ** Generic error response flows
82 - ** Check naming conventions flows, properties and XSD
83 - ** Split messages in on-ramp – not later
84 + * Validate routing
85 + * Generic error response flows
86 + * Check naming conventions flows, properties and XSD
87 + * Split messages in on-ramp – not later
84 84  * Deploy
85 - ** Check properties
86 - ** Avoid too many different flow versions – max. 2
87 - ** Remove test packages that are deployed
89 + * Check properties
90 + * Avoid too many different flow versions – max. 2
91 + * Remove test packages that are deployed
88 88  * Manage
89 - ** All alerts mapped to Customer Support
90 - ** All messages can be explained
91 - ** Avoid code mappings
92 - ** Enable default alerts
93 + * All alerts mapped to Customer Support
94 + * All messages can be explained
95 + * Avoid code mappings
96 + * Enable default alerts
93 93  * Architecture
94 - ** Deploy connector close to the source/target system
95 - ** Ensure ACCP and PROD are exact copies
96 - ** Cloud over on-premise
97 - ** No hard-coded variable – use properties
98 + * Deploy connector close to the source/target system
99 + * Ensure ACCP and PROD are exact copies
100 + * Cloud over on-premise
101 + * No hard-coded variable – use properties
98 98  
99 -== 4. Key takeaways ==
103 +===== Practice =====
100 100  
105 +== 4. Assignment ==
106 +
107 +See how peer reviews are currently implemented within the projects on which you work to see if you can learn something from the information you have gathered via this microlearning.
108 +
109 +== 5. Key takeaways ==
110 +
101 101  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.
102 102  
103 -== 5. Suggested Additional Readings ==
104 104  
105 -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:
106 106  
107 -* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
108 -** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
109 -*** [[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"]]
110 -* [[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"]]
111 -)))((({{toc/}}))){{/container}}{{/container}}
115 +== 6. Suggested Additional Readings ==
116 +
117 +You will find plenty background items available on the Internet.
118 +
119 +== 7. Silent demonstration video ==
120 +
121 +As this is a more theoretical microlearning we have no video for this.
122 +
123 +</div>
124 +
125 +</div>
126 +</div>
127 +
128 +{{/html}}