Wiki source code of Peer reviews

Version 22.6 by Danniar Firdausy on 2024/09/18 14:40

version	line-number	content
15.1	1	{{container}}{{container layoutStyle="columns"}}(((
1.1	2
22.6	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.
	4
15.1	5	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
1.1	6
	7	== 1. Prerequisites ==
	8
	9	* Basic knowledge of the eMagiz platform
	10
	11	== 2. Key concepts ==
	12
22.6	13	By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production.
1.1	14
22.6	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
15.1	19	[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
1.1	20
22.6	21	Key benefits of peer reviews:
1.1	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
21.1	30	=== 3.1 Who and when ===
1.1	31
21.1	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
1.1	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
18.1	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.
1.1	45	* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
	46
21.1	47	=== 3.3 Considerations for reviewer ===
1.1	48
	49	Here are some things to keep in mind when peer reviewing the work .
	50
	51	* Ask questions
18.1	52	** How does this work?
	53	** Why did you decide to …?
	54	** Did you think about …?
1.1	55	* Spot (incorrect) assumptions
	56	* Check application of best practices – see next slide
18.1	57	** Modelling / coding patterns
	58	** Naming conventions
	59	** Errors / warnings
1.1	60	* Notice non-standard / unusual / abnormal things
18.1	61	** Make sure this is documented, mainly for future changes. Annotations are very useful here.
1.1	62
	63	=== 3.3 Peer review items per ILM Phase ===
	64
	65	* Capture
18.1	66	** 100% filled
	67	** Connection method clear
	68	** Authentication method clear
	69	** Definitions loaded
	70	** Sizing impact understood and valid
1.1	71	* Design
18.1	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
1.1	78	* Create
18.1	79	** Validate routing
	80	** Generic error response flows
	81	** Check naming conventions flows, properties and XSD
	82	** Split messages in on-ramp – not later
1.1	83	* Deploy
18.1	84	** Check properties
	85	** Avoid too many different flow versions – max. 2
	86	** Remove test packages that are deployed
1.1	87	* Manage
18.1	88	** All alerts mapped to Customer Support
	89	** All messages can be explained
	90	** Avoid code mappings
	91	** Enable default alerts
1.1	92	* Architecture
18.1	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
1.1	97
22.1	98	== 4. Key takeaways ==
1.1	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
22.1	102	== 5. Suggested Additional Readings ==
1.1	103
22.3	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:
1.1	105
22.3	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"]]
22.5	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"]]
22.1	110	)))((({{toc/}}))){{/container}}{{/container}}

Wiki source code of Peer reviews

Navigation