Skip to Content

Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 13.1
edited by eMagiz
on 2022/05/17 09:10
Change comment: There is no comment for this version
To version 20.1
edited by Erik Bakker
on 2022/08/30 08:28
Change comment: There is no comment for this version

Summary

Details

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