Changes for page Peer reviews

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.eMagiz
	1	+XWiki.ebakker

Content

...	...	@@ -3,9 +3,6 @@
3	3
4	4	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
6		-* Last update: April 22nd, 2021
7		-* Required reading time: 8 minutes
8		-
9	9	== 1. Prerequisites ==
10	10
11	11	* Basic knowledge of the eMagiz platform
...	...	@@ -25,8 +25,6 @@
25	25	* Architecture challenge and verification
26	26	* Find alternative solutions
27	27
28		-
29		-
30	30	== 3. Running peer reviews in eMagiz ==
31	31
32	32	=== 3.1 Considerations for reviewee ===
...	...	@@ -36,8 +36,8 @@
36	36	* Quickly explain the story / task / background
37	37	* Quickly show the working result if applicable / practical
38	38	* Talk through the solution while showing the models / code
39		- * Just trying to explain your work to someone else will help spot mistakes
40		- * 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.
41	41	* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
42	42
43	43	=== 3.2 Considerations for reviewer ===
...	...	@@ -45,54 +45,52 @@
45	45	Here are some things to keep in mind when peer reviewing the work .
46	46
47	47	* Ask questions
48		- * How does this work?
49		- * Why did you decide to …?
50		- * Did you think about …?
	43	+ ** How does this work?
	44	+ ** Why did you decide to …?
	45	+ ** Did you think about …?
51	51	* Spot (incorrect) assumptions
52	52	* Check application of best practices – see next slide
53		- * Modelling / coding patterns
54		- * Naming conventions
55		- * Errors / warnings
	48	+ ** Modelling / coding patterns
	49	+ ** Naming conventions
	50	+ ** Errors / warnings
56	56	* Notice non-standard / unusual / abnormal things
57		- * 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.
58	58
59	59	=== 3.3 Peer review items per ILM Phase ===
60	60
61	61	* Capture
62		- * 100% filled
63		- * Connection method clear
64		- * Authentication method clear
65		- * Definitions loaded
66		- * 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
67	67	* Design
68		- * Check solution architecture validity
69		- * Design 100% filled and clear
70		- * CDM Root entity mapped
71		- * Set as mapped – avoid line mapping
72		- * Use annotation where possible
73		- * 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
74	74	* Create
75		- * Validate routing
76		- * Generic error response flows
77		- * Check naming conventions flows, properties and XSD
78		- * 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
79	79	* Deploy
80		- * Check properties
81		- * Avoid too many different flow versions – max. 2
82		- * 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
83	83	* Manage
84		- * All alerts mapped to Customer Support
85		- * All messages can be explained
86		- * Avoid code mappings
87		- * Enable default alerts
	79	+ ** All alerts mapped to Customer Support
	80	+ ** All messages can be explained
	81	+ ** Avoid code mappings
	82	+ ** Enable default alerts
88	88	* Architecture
89		- * Deploy connector close to the source/target system
90		- * Ensure ACCP and PROD are exact copies
91		- * Cloud over on-premise
92		- * 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
93	93
94		-
95		-
96	96	== 4. Assignment ==
97	97
98	98	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.
...	...	@@ -101,8 +101,6 @@
101	101
102	102	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.
103	103
104		-
105		-
106	106	== 6. Suggested Additional Readings ==
107	107
108	108	You will find plenty background items available on the Internet.
...	...	@@ -109,6 +109,4 @@
109	109
110	110	== 7. Silent demonstration video ==
111	111
112		-As this is a more theoretical microlearning we have no video for this.
113		-
114		-)))((({{toc/}}))){{/container}}{{/container}}
	103	+As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}