แบบฝึกหัดการตรวจสอบโค้ด: วิธีใช้การตรวจสอบโดยเพื่อนร่วมงานเพื่อพัฒนาทักษะการวิเคราะห์และการตัดสินใจทางเทคนิค

นักพัฒนาส่ง Pull Request ที่เพิ่มการคำนวณส่วนลดลงในระบบชำระเงิน การทดสอบผ่านหมดและส่วนต่างของโค้ดก็ไม่มาก ผู้ตรวจสอบอนุมัติภายในสองนาทีด้วยข้อความ "LGTM" สามเดือนต่อมา เพื่อนร่วมทีมจำเป็นต้องแก้ไขฟังก์ชันเดียวกันนี้และพบว่ามันผสมผสานกฎการกำหนดราคา การปัดเศษ และการเข้าถึงฐานข้อมูลไว้ในที่เดียวกัน ไม่มีใครสามารถบอกได้อย่างมั่นใจว่ามันทำอะไรได้บ้าง

นี่เป็นเพียงสถานการณ์จำลอง ไม่ใช่เหตุการณ์ที่เกิดขึ้นจริง มันแสดงให้เห็นว่าการตรวจสอบโค้ดโดยเพื่อนร่วมงานควรให้ผลลัพธ์อย่างไรเมื่อนำไปใช้เป็นกิจกรรมการเรียนรู้: ผู้ตรวจสอบที่สามารถมองเห็นการเปลี่ยนแปลงที่เป็นไปได้ ระบุปัญหาที่ยังไม่ใช่บั๊ก และอธิบายในลักษณะที่ผู้เขียนสามารถนำไปปฏิบัติได้

คู่มือนี้จัดทำขึ้นสำหรับหัวหน้าทีมส่งเสริมวิศวกรรมและผู้จัดการฝ่ายวิศวกรรม โดยแสดงวิธีการออกแบบ แบบฝึกหัดการตรวจสอบโค้ด ซึ่งเป็นการสร้างทักษะนั้นขึ้นมาอย่างตั้งใจ แทนที่จะหวังว่าผู้ตรวจสอบจะเรียนรู้มันเองจากคิว เนื้อหาจะครอบคลุมถึงปัญหาด้านประสิทธิภาพ ช่องว่างที่ต้องวินิจฉัย วิธีการวางโครงสร้างการเตรียมตัวและการฝึกฝน ตัวอย่างการใช้งานจริง และวิธีการตรวจสอบว่าทักษะดังกล่าวสามารถนำไปใช้ในการตรวจสอบจริงได้หรือไม่ ควรให้วิศวกรอาวุโสตรวจสอบความถูกต้องของทุกกรณี ข้อบกพร่อง และเกณฑ์ก่อนนำไปใช้

แบบฝึกหัดการตรวจสอบโค้ดคืออะไร?

แบบฝึกหัดการตรวจสอบโค้ดเป็นงานฝึกฝนที่มีโครงสร้าง ซึ่งนักพัฒนาจะตรวจสอบการเปลี่ยนแปลงที่เตรียมไว้ อธิบายสิ่งที่พบและเหตุผลว่าทำไมจึงสำคัญ และรับข้อเสนอแนะเกี่ยวกับคุณภาพของคำอธิบายนั้น แบบฝึกหัดเหล่านี้แตกต่างจากการตรวจสอบที่ทีมของคุณทำทุกวัน การเปลี่ยนแปลงนั้นถูกเลือกไว้ล่วงหน้า ปัญหาที่เกี่ยวข้องก็ทราบอยู่แล้ว และเป้าหมายคือการพัฒนาผู้ตรวจสอบมากกว่าการปล่อยเวอร์ชันที่เปลี่ยนแปลงไปใช้งานจริง

ข้อเท็จจริงด่วน

1. อธิบายปัญหาด้านประสิทธิภาพ

เริ่มต้นด้วยโจทย์ในประโยคเดียว: เมื่อพบการเปลี่ยนแปลง ผู้ตรวจสอบต้องอธิบายสิ่งที่พบ ความสำคัญ และสิ่งที่ผู้เขียนสามารถทำได้ คำว่า "อธิบาย" นั้นสำคัญมาก การค้นพบปัญหาเป็นเพียงครึ่งหนึ่งของทักษะ การอธิบายให้เพื่อนร่วมงานที่มีมุมมองแตกต่างกันเข้าใจ พิจารณา และลงมือทำได้ คืออีกครึ่งหนึ่ง

งานวิจัยเกี่ยวกับการตรวจสอบโค้ดสมัยใหม่สนับสนุนให้มองข้ามการล่าหาบั๊กเพียงอย่างเดียว ในการศึกษาที่ Microsoft บาเชลลีและเบิร์ดได้สังเกต สัมภาษณ์ และสำรวจนักพัฒนาและผู้จัดการ พวกเขาพบว่าการค้นหาข้อบกพร่องยังคงเป็นแรงจูงใจหลักในการตรวจสอบ แต่การตรวจสอบนั้นไม่ได้เน้นที่ข้อบกพร่องมากเท่าที่หลายคนคาดหวัง นอกจากนี้ยังให้ประโยชน์อื่นๆ เช่น การแบ่งปันความรู้ การรับรู้ของทีม และแนวทางแก้ไขทางเลือก และนักวิจัยได้อธิบายว่าความเข้าใจในโค้ดและการเปลี่ยนแปลงเป็นหัวใจสำคัญของการตรวจสอบ (บาเชลลีและเบิร์ด, ICSE 2013(นี่เป็นการศึกษาทีมงานของบริษัทแห่งหนึ่ง ดังนั้นจงใช้เป็นเหตุผลในการออกแบบเพื่อให้เกิดความเข้าใจ ไม่ใช่ใช้เป็นอัตราประเมินสำหรับทีมของคุณ)

มาตรฐานการตรวจสอบที่ Google เผยแพร่ก็ชี้ไปในทิศทางเดียวกัน โดยระบุว่าผู้ตรวจสอบควรอนุมัติการเปลี่ยนแปลงก็ต่อเมื่อการเปลี่ยนแปลงนั้นช่วยปรับปรุงคุณภาพโดยรวมของโค้ดได้อย่างแน่นอน แม้ว่าจะไม่สมบูรณ์แบบก็ตาม และระบุว่าการตรวจสอบสามารถสอนสิ่งใหม่ๆ ให้กับนักพัฒนาได้ ดังนั้นความคิดเห็นที่ช่วยให้ผู้อื่นเรียนรู้จึงเป็นที่ยินดี (แนวทางปฏิบัติทางวิศวกรรมของ Googleแหล่งข้อมูลทั้งสองอธิบายว่าการวิจารณ์เป็นสถานที่ที่ใช้ในการตัดสินและส่งต่อความคิดเห็น นั่นคือสิ่งที่แบบฝึกหัดของคุณควรฝึกฝน

2. วิเคราะห์ช่องว่างด้านการเรียนรู้และบริบท

เปรียบเทียบงานนี้กับสิ่งที่หลักสูตรปัจจุบันของคุณปฏิบัติและประเมินผล

1. แนวทางปฏิบัติในปัจจุบันใช้โจทย์งานจริงหรือไม่? หากผู้ตรวจสอบใหม่เรียนรู้โดยการอ่านคู่มือสไตล์แล้วตรวจสอบ pull request จริง พวกเขาจะได้ฝึกฝนกับงานจริงโดยไม่มีที่ว่างให้ทำผิดพลาด แต่ถ้าการประเมินเป็นการทดสอบเกี่ยวกับมารยาทในการตรวจสอบ มันจะวัดความสามารถในการจดจำกฎ ไม่ใช่ความสามารถในการนำไปใช้กับการเปลี่ยนแปลง
2. ความต้องการด้านการรับรู้คืออะไร? ในอนุกรมวิธานของบลูมฉบับปรับปรุงใหม่ การตัดสินว่าการออกแบบนั้นเหมาะสมหรือไม่และการชั่งน้ำหนักข้อดีข้อเสียจะอยู่ในระดับการวิเคราะห์และการประเมิน ในขณะที่การเสนอโครงสร้างที่ดีกว่าจะอยู่ในระดับการสร้าง หากแบบฝึกหัดของคุณถามเพียงแค่ "โค้ดนี้ทำอะไร" นั่นหมายความว่าแบบฝึกหัดนั้นหยุดอยู่ที่ระดับความเข้าใจ คู่มือของเราเกี่ยวกับ การจับคู่กิจกรรมการเรียนรู้กับอนุกรมวิธานของบลูม แสดงวิธีการจับคู่กิจกรรมให้เหมาะสมกับระดับ
3. มีปัจจัยอื่นนอกเหนือจากทักษะที่เป็นอุปสรรคอยู่หรือไม่? ตรวจสอบเวลาในการตรวจสอบ เครื่องมือ การรับผิดชอบ และบรรทัดฐานของทีม หากผู้ตรวจสอบมีเวลาเพียงห้านาทีต่อ pull request การตรวจสอบก็จะไม่ก่อให้เกิดคำอธิบายที่รอบคอบ หากผู้เขียนมองทุกความคิดเห็นเป็นการวิจารณ์ ผู้ตรวจสอบก็จะลดทอนข้อบกพร่องลงจนกระทั่งไม่พูดอะไรเลย รายงานสาเหตุเหล่านี้ไปยังผู้ที่สามารถแก้ไขได้

3. การเตรียมการออกแบบ การฝึกฝน และการให้ข้อเสนอแนะ

มอบหมายงานที่แตกต่างกันให้แต่ละขั้นตอน

การเตรียมการ. ตรวจสอบสิ่งที่ผู้ตรวจสอบต้องการก่อนเริ่มงาน: รายการตรวจสอบการตรวจสอบของทีม หลักการออกแบบที่ใช้ และวิธีการอ่านส่วนต่างในเครื่องมือของคุณ ให้กระบวนการนี้ดำเนินไปตามจังหวะของตนเองและใช้เวลาสั้นๆ การตรวจสอบความจำยืนยันเพียงข้อกำหนดเบื้องต้นเท่านั้น และไม่ใช่หลักฐานว่าบุคคลนั้นสามารถตรวจสอบได้

การปฏิบัติ ใช้การเปลี่ยนแปลงที่เตรียมไว้ล่วงหน้าโดยมีข้อกังวลที่กำหนดไว้จำนวนเล็กน้อยที่แตกต่างกัน เช่น ข้อผิดพลาดด้านความถูกต้อง ปัญหาด้านการบำรุงรักษา เช่น ความรับผิดชอบที่ผสมปนเปกันในตัวอย่างเริ่มต้น ชื่อที่ไม่ชัดเจนหรือการทดสอบที่ขาดหายไป และโค้ดบางส่วนที่ใช้งานได้ดี ขอให้ผู้ตรวจสอบเขียนความคิดเห็นที่พวกเขาต้องการแสดง จัดลำดับข้อกังวล และบอกว่าพวกเขาต้องการข้อมูลเพิ่มเติมอะไรบ้าง บทเรียนภาคปฏิบัติของ CodeRefinery แสดงให้เห็นถึงรูปแบบ: ผู้คนเปิดคำขอพูลที่มีข้อผิดพลาดเล็กน้อยและข้อผิดพลาดที่ใหญ่กว่า จากนั้นตรวจสอบในฐานะเพื่อนร่วมงาน (CodeRefinery, การฝึกฝนการตรวจสอบโค้ดสร้างของคุณเองจากโค้ดเบสของคุณเอง เพื่อให้ข้อกำหนดและข้อแลกเปลี่ยนต่างๆ เป็นจริง

ฟีดแบ็ก เชื่อมโยงเข้ากับการตัดสินใจของผู้ตรวจสอบ การบอกว่า "คุณสังเกตเห็นปัญหาการปัดเศษ แต่ความคิดเห็นของคุณบอกว่า 'ดูเหมือนผิดปกติ' โดยไม่ได้ระบุว่าข้อมูลป้อนเข้าใดทำให้เกิดปัญหา" นั้นมีประโยชน์มากกว่าการบอกว่า "พบ 2 ใน 4"

การป้อนข้อมูลแบบเรียลไทม์หรือการตรวจสอบแบบไม่พร้อมกัน? การรับฟังความคิดเห็นแบบเรียลไทม์จะเพิ่มคุณค่าสูงสุดเมื่อข้อกังวลนั้นคลุมเครือ และผู้ตรวจสอบจะได้เรียนรู้จากการฟังวิศวกรอาวุโสอธิบายว่าทำไมพวกเขาถึงควรหยิบยกประเด็นนั้นขึ้นมา หรือปล่อยผ่านไป การตรวจสอบแบบไม่พร้อมกันนั้นเพียงพอสำหรับการเปรียบเทียบความคิดเห็นกับการตรวจสอบโดยผู้เชี่ยวชาญที่มีคำอธิบายประกอบ

4. ลองทำตัวอย่างที่สมจริงดู

เป็นเพียงตัวอย่างเท่านั้น ผู้จัดการฝ่ายวิศวกรรมควรตรวจสอบความถูกต้องของกรณีศึกษาและเกณฑ์การตอบคำถามก่อนนำไปใช้

กรณี. การเปลี่ยนแปลงนี้เพิ่มการคำนวณส่วนลดลงในบริการชำระเงิน และผ่านการทดสอบแล้ว ในฟังก์ชันหนึ่ง ระบบจะใช้ส่วนลดแบบเปอร์เซ็นต์และส่วนลดคงที่ ปัดเศษผลลัพธ์ บันทึกข้อมูลลงฐานข้อมูล และส่งเหตุการณ์ มีการทดสอบหนึ่งรายการสำหรับส่วนลดแบบเปอร์เซ็นต์เดียว

ภารกิจนั้น ผู้รีวิวจะเขียนความคิดเห็นที่ตนเองอยากจะแสดง จัดลำดับข้อกังวล และระบุสิ่งที่ตนเองจำเป็นต้องรู้ก่อนที่จะอนุมัติ

เป็นการลองทำครั้งแรก "ดูดี การทดสอบผ่านแล้ว อาจจะลองแบ่งการทดสอบออกเป็นส่วนๆ ดูไหม?" ผู้ตรวจสอบสังเกตเห็นบางอย่าง แต่ไม่ได้บอกว่าอะไร ทำไมมันถึงสำคัญ หรือควรทำอย่างไร ผู้เขียนจึงไม่สามารถดำเนินการใดๆ ได้

ให้ข้อเสนอแนะและลองใหม่อีกครั้ง ผู้ดำเนินรายการถามว่า: การเปลี่ยนแปลงในอนาคตต่อฟังก์ชันนี้จะเสี่ยงต่อการเกิดข้อผิดพลาดอะไรบ้าง? คุณจะขอให้ผู้เขียนเพิ่มอะไรก่อนที่จะอนุมัติ? ในส่วนการลองใหม่นั้นขอให้แสดงความคิดเห็นเฉพาะเจาะจงเกี่ยวกับข้อกังวลแต่ละข้อ พร้อมเหตุผลและข้อเสนอแนะ

ความพยายามที่หนักแน่นกว่าเดิม "ฟังก์ชันนี้ใช้ส่วนลดสองประเภท ปัดเศษ บันทึก และเผยแพร่เหตุการณ์ ดังนั้นการเปลี่ยนแปลงการปัดเศษอาจเปลี่ยนแปลงทั้งสิ่งที่เราจัดเก็บและสิ่งที่เราเผยแพร่ในเวลาเดียวกัน ผมขอให้ย้ายกฎการกำหนดราคาไปอยู่ในฟังก์ชันบริสุทธิ์ที่เราสามารถทดสอบได้ด้วยตัวเอง การทดสอบเดียวครอบคลุมเฉพาะส่วนลดเป็นเปอร์เซ็นต์เท่านั้น ผมขอให้มีส่วนลดคงที่และคำสั่งซื้อที่ทำให้ผลรวมเป็นศูนย์ ผมไม่แน่ใจว่าเหตุการณ์จะทำงานเมื่อผลรวมเป็นศูนย์หรือไม่ ดังนั้นผมจึงอยากถามผู้เขียน" โปรดสังเกตว่าความคิดเห็นนี้ระบุถึงข้อกังวล ให้เหตุผล ให้คำแนะนำที่เป็นรูปธรรม และระบุสิ่งที่ผู้ตรวจสอบไม่ทราบ

5. ประเมินศักยภาพและวางแผนการถ่ายโอน

หลักฐานแสดงถึงความสามารถคือ ประสิทธิภาพในการรับมือกับการเปลี่ยนแปลงใหม่ที่ผู้ประเมินยังไม่เคยเห็นมาก่อน ให้คะแนนความถูกต้องของสิ่งที่ค้นพบและความมีประโยชน์ของคำอธิบาย โดยใช้เกณฑ์การให้คะแนนแบบง่ายๆ คือ 0 ถึง 2 ต่อเกณฑ์แต่ละข้อ:

เกณฑ์การให้คะแนน: 0 หมายถึงไม่มีหรือไม่ได้รับการสนับสนุน 1 หมายถึงมีบางส่วนแต่ขาดหายไปในส่วนที่สำคัญ และ 2 หมายถึงสมบูรณ์และมีเหตุผลรองรับตามเกณฑ์ที่ตกลงกันไว้ กำหนดข้อผิดพลาดที่สำคัญแยกต่างหาก เช่น การอนุมัติการเปลี่ยนแปลงที่มีความเสี่ยงต่อการสูญเสียข้อมูล เพื่อให้คะแนนโดยรวมที่ดีไม่สามารถปกปิดข้อผิดพลาดที่สำคัญได้ ปรับเกณฑ์ร่วมกับผู้จัดการฝ่ายวิศวกรรม เกณฑ์นี้เป็นเพียงข้อเสนอเริ่มต้น ไม่ใช่มาตรฐานความพร้อมที่ได้รับการตรวจสอบแล้ว สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเหตุผลในการให้คะแนน โปรดดูคู่มือของเรา ออกแบบแบบฝึกหัดเชิงโต้ตอบพร้อมข้อเสนอแนะที่เป็นประโยชน์.

วางแผนสำหรับการถ่ายโอนความรู้ หลังจากเสร็จสิ้นการฝึกปฏิบัติ ให้ตรวจสอบตัวอย่างการประเมินจริงของผู้ประเมินอีกครั้งในอีกไม่กี่สัปดาห์ต่อมา โดยใช้เกณฑ์เดียวกัน เปรียบเทียบกับข้อมูลพื้นฐานที่บันทึกไว้ก่อนการฝึกอบรม และกำหนดกลุ่มเป้าหมายและช่วงเวลาล่วงหน้า พิจารณาการเปลี่ยนแปลงอื่นๆ ที่เกิดขึ้นในช่วงเวลาเดียวกัน เช่น เครื่องมือประเมินใหม่ หรือการเปลี่ยนแปลงบุคลากร ก่อนที่จะให้เครดิตแก่การฝึกปฏิบัติ

6. ลองทำแบบฝึกหัดแบบสดๆ หรือแบบเรียนรู้ด้วยตนเองโดยใช้ AhaSlides

คุณสามารถจัดกิจกรรมนี้ในเวิร์กช็อป หรือให้ผู้ตรวจสอบดำเนินการด้วยตนเองก็ได้ ในการประชุมสด ให้แสดงการเปลี่ยนแปลงที่เตรียมไว้ และใช้สไลด์แบบโต้ตอบสำหรับการอภิปราย:

1. เลือกคำตอบ สำหรับคำถาม "คุณจะหยิบยกประเด็นใดขึ้นมาเป็นอันดับแรก?" โดยให้ประเด็นที่กำหนดไว้ล่วงหน้าเป็นตัวเลือก แสดงลำดับก่อนที่จะเปิดเผยลำดับของคุณเอง
2. เปิดสิ้นสุดแล้ว สำหรับคำถาม "เขียนความคิดเห็นที่คุณอยากจะเขียน" ผู้รีวิวสามารถเปรียบเทียบคำพูดของตนเองกับผู้อื่นได้ ซึ่งเป็นจุดที่แสดงให้เห็นถึงทักษะการอธิบาย
3. ระดับคะแนน สำหรับคำถาม "สถานการณ์นี้ร้ายแรงแค่ไหน?" เพื่อให้กลุ่มได้เห็นว่าความคิดเห็นแตกต่างกันอย่างไร และได้พูดคุยถึงสาเหตุ

สำหรับผู้ตรวจสอบที่ไม่สามารถเข้าร่วมได้ สามารถใช้ลำดับขั้นตอนเดียวกันนี้ได้โดยเรียนรู้ด้วยตนเอง โดยจะมีบทวิจารณ์ของผู้เชี่ยวชาญพร้อมคำอธิบายประกอบแสดงอยู่หลังคำตอบแต่ละข้อ โปรดถือว่าข้อกล่าวอ้างใดๆ เกี่ยวกับการทำงานของโค้ด การบูรณาการ หรือคุณสมบัติของ AI ยังไม่ได้รับการยืนยัน จนกว่าคุณจะได้ทดลองใช้กับเนื้อหาของคุณเอง

หากคุณฝึกอบรมผู้ตรวจสอบโค้ดด้วย AI ด้วย โปรดดูคู่มือประกอบของเราเกี่ยวกับเรื่องนี้ การฝึกอบรมการตรวจสอบโค้ดที่สร้างโดย AIโพสต์นั้นเกี่ยวกับการตรวจสอบผลลัพธ์ที่สร้างขึ้น ส่วนโพสต์นี้เกี่ยวกับการที่ผู้คนตรวจสอบงานของกันและกัน และวิธีการที่พวกเขาอธิบายสิ่งที่พวกเขาพบ

ข้อจำกัดที่อาจยังคงอยู่

• ถึงเวลาตรวจสอบแล้ว การเขียนความคิดเห็นอย่างรอบคอบใช้เวลานานกว่าการตอบแบบ "LGTM" และกำหนดเวลาที่จำกัดทำให้ต้องเขียนเวอร์ชันสั้นลง
• ระเบียบของทีม หากคำติชมถูกตีความว่าเป็นคำวิจารณ์ส่วนบุคคล ผู้รีวิวจะลดทอนหรือตัดทอนข้อค้นพบของตนออกไป
• ความคุ้มครองตามคดี แบบฝึกหัดหนึ่งแสดงให้เห็นถึงข้อกังวลหลายประการ คะแนนไม่ได้บ่งบอกถึงวิจารณญาณของผู้ประเมินโดยทั่วไป
• โอน ประสิทธิภาพในการอบรมเชิงปฏิบัติการไม่เหมือนกับประสิทธิภาพในแถวที่แออัด ดังนั้นควรตรวจสอบรีวิวจากผู้ใช้งานจริงด้วย

แจ้งปัญหาเหล่านี้ให้ผู้สนับสนุนทราบตั้งแต่เนิ่นๆ และวางแผนแก้ไขแยกต่างหาก แบบฝึกหัดช่วยปรับปรุงสิ่งที่ผู้ตรวจสอบสามารถมองเห็นและอธิบายได้ แต่ไม่ได้สร้างเวลาหรือมาตรฐานขึ้นมาเอง

คำถามที่พบบ่อย

แบบฝึกหัดการตรวจสอบโค้ดคืออะไร?

นี่คือแบบฝึกหัดที่จัดเตรียมไว้ล่วงหน้า ซึ่งนักพัฒนาจะตรวจสอบการเปลี่ยนแปลงโดยคำนึงถึงปัญหาที่ทราบอยู่แล้ว เขียนความคิดเห็นที่ตนเองจะเขียน และรับข้อเสนอแนะเกี่ยวกับความถูกต้องและประโยชน์ใช้สอย จุดมุ่งหมายคือการพัฒนาทักษะของผู้ตรวจสอบ ไม่ใช่การปล่อยการเปลี่ยนแปลงนั้นสู่การใช้งานจริง

คุณจะประเมินได้อย่างไรว่าวิจารณญาณของผู้รีวิวดีขึ้นหรือไม่?

เสนอการเปลี่ยนแปลงใหม่ที่พวกเขาไม่เคยเห็นมาก่อน แล้วให้คะแนนข้อค้นพบและคำอธิบายตามเกณฑ์ที่ตกลงกันไว้ จากนั้นตรวจสอบตัวอย่างรีวิวจริงอีกครั้งในอีกไม่กี่สัปดาห์ต่อมา แบบทดสอบเกี่ยวกับกฎการรีวิวจะช่วยยืนยันเฉพาะข้อกำหนดเบื้องต้นเท่านั้น

การตรวจสอบโค้ดโดยเพื่อนร่วมงานมีจุดประสงค์หลักเพื่อค้นหาข้อผิดพลาดใช่หรือไม่?

การค้นหาข้อบกพร่องยังคงเป็นแรงจูงใจหลัก แต่จากการศึกษาของ Microsoft พบว่า การตรวจสอบนั้นไม่ได้เน้นที่ข้อบกพร่องมากเท่าที่คาดไว้ และยังช่วยส่งเสริมการแบ่งปันความรู้และการสร้างความตระหนักรู้ในทีมอีกด้วย จึงควรออกแบบแบบฝึกหัดที่ให้รางวัลแก่การอธิบายและความเข้าใจ รวมถึงจำนวนข้อบกพร่องที่พบด้วย

จะเริ่มที่ไหนดี

เลือกการเปลี่ยนแปลงประเภทใดประเภทหนึ่งที่ทีมของคุณตรวจสอบบ่อย เขียนคำอธิบายประสิทธิภาพ ขอให้วิศวกรอาวุโสเตรียมการเปลี่ยนแปลงหนึ่งรายการพร้อมข้อกังวลที่กำหนดไว้ล่วงหน้าสามหรือสี่ข้อ และร่างเกณฑ์การประเมินสามข้อโดยใช้มาตราส่วน 0 ถึง 2 พร้อมรายการข้อผิดพลาดที่สำคัญ ทดลองใช้กับกลุ่มเล็กๆ จากนั้นเปรียบเทียบการตรวจสอบจริงครั้งต่อไปกับเกณฑ์พื้นฐาน

หากต้องการเรียนรู้วิธีการดำเนินการทบทวนแบบสดๆ กับทีมของคุณเอง และนำกลับมาใช้ใหม่ได้ตามความสะดวกในภายหลัง ลองศึกษา AhaSlides ดู