Do Code Reviews Promptly! (รีวิวโค้ดให้เร็วที่สุด!)

ถ้าคุณต้องการทำ code review และไม่ได้ทำ pair programming ให้รีวิวให้เร็วที่สุดหลังจากการเปลี่ยนแปลงถูกส่งเข้ามา และพูดคุย feedback ในแบบ synchronous ให้มากที่สุดเท่าที่จะทำได้ ควรเป็นแบบเจอหน้ากับผู้รีวิวโดยตรงถ้าเป็นไปได้

Ensemble programming (การเขียนโปรแกรมแบบกลุ่ม)

Ensemble programming (หรือที่รู้จักกันในชื่อ mob programming 14 ) บางครั้งก็ถูกพูดถึงว่าเป็นวิธีทำ code review แบบ inline ด้วย ensemble programming กลุ่มคนที่ใหญ่ขึ้น (อาจจะทั้งทีม) ทำงานร่วมกันในการเปลี่ยนแปลงหนึ่งๆ มันเป็นเรื่องของการทำงานร่วมกันแก้ปัญหาและรับ input จากคนจำนวนมากเป็นหลัก

จากทีมที่ผมเคยพูดคุยด้วยที่ใช้ ensemble programming ส่วนใหญ่ใช้มันเป็นครั้งคราวสำหรับปัญหาที่ยากเป็นพิเศษหรือการเปลี่ยนแปลงที่สำคัญเท่านั้น แต่การพัฒนาส่วนใหญ่ก็ยังเกิดขึ้นนอกกิจกรรม ensemble ด้วยเช่นกัน ดังนั้น แม้ว่ากิจกรรม ensemble programming จะให้การรีวิวการเปลี่ยนแปลงที่ทำระหว่าง ensemble เองอย่างเพียงพอ และในลักษณะที่ synchronous มาก คุณก็ยังต้องมีวิธีเพื่อให้แน่ใจว่าการเปลี่ยนแปลงที่ทำนอกกลุ่ม mob ก็ได้รับการรีวิวด้วย

บางคนอาจแย้งว่าคุณแค่ต้องรีวิวการเปลี่ยนแปลงที่มีความเสี่ยงสูงเท่านั้น ดังนั้นการรีวิวแค่ในฐานะส่วนหนึ่งของ ensemble ก็เพียงพอแล้ว ควรสังเกตว่าผู้เขียน Accelerate พบอย่างน่าประหลาดใจว่า ไม่มี ความสัมพันธ์ระหว่างประสิทธิภาพการส่งมอบซอฟต์แวร์กับการรีวิวเฉพาะการเปลี่ยนแปลงที่มีความเสี่ยงสูง เมื่อเทียบกับความสัมพันธ์เชิงบวกเมื่อการเปลี่ยนแปลงทั้งหมดถูก peer review ดังนั้นถ้าคุณอยากทำ ensemble programming ก็ทำไปเลย! แต่คุณอาจอยากพิจารณารีวิวการเปลี่ยนแปลงอื่นๆ ที่ทำนอก ensemble ด้วยเช่นกัน

ส่วนตัวแล้ว ผมมีข้อกังขาลึกๆ เกี่ยวกับบางแง่มุมของ ensemble programming คุณจะพบว่าทีมของคุณเป็นกลุ่มคนที่มีความหลากหลายทางระบบประสาท (neurodiverse) และความไม่สมดุลของอำนาจใน ensemble อาจบั่นทอนเป้าหมายของการแก้ปัญหาร่วมกันได้มากขึ้นไปอีก ไม่ใช่ทุกคนจะรู้สึกสบายใจที่จะทำงานเป็นกลุ่ม และ ensemble ก็คือแบบนั้นแน่นอน บางคนจะรุ่งเรืองในสภาพแวดล้อมแบบนี้ ในขณะที่บางคนจะรู้สึกไม่สามารถมีส่วนร่วมได้เลย เมื่อผมหยิบยกประเด็นนี้ขึ้นมาคุยกับผู้สนับสนุน ensemble programming บางคน ผมได้รับคำตอบหลากหลาย ซึ่งส่วนใหญ่สรุปได้ว่าเชื่อว่าถ้าคุณสร้างสภาพแวดล้อม ensemble ที่ถูกต้อง ทุกคนจะสามารถ "ออกจากเปลือกของตัวเองและมีส่วนร่วมได้" ขอพูดตรงๆ ว่าหลังจากบทสนทนาชุดนั้น ผมกลอกตาจนเกือบจะตาบอด ต้องยุติธรรมหน่อยว่าความกังวลแบบเดียวกันนี้ก็สามารถหยิบยกขึ้นมาพูดถึง pair programming ได้เช่นกัน!

แม้ผมจะไม่สงสัยเลยว่าผู้สนับสนุน ensemble programming หลายคนจะไม่มองข้ามหรือไม่รับรู้ประเด็นนี้เท่าที่ผมยกตัวอย่างมา แต่สิ่งสำคัญคือต้องจำไว้ว่าการสร้างพื้นที่ทำงานที่เปิดกว้าง (inclusive) ส่วนหนึ่งคือการเข้าใจว่าจะสร้างสภาพแวดล้อมที่สมาชิกทุกคนในทีมสามารถมีส่วนร่วมได้อย่างเต็มที่ในแบบที่ปลอดภัยและสบายใจสำหรับพวกเขาได้อย่างไร และอย่าหลอกตัวเองว่าแค่เพราะคุณเอาทุกคนมาอยู่ในห้องเดียวกัน ทุกคนก็จะมีส่วนร่วมจริงๆ ถ้าคุณอยากได้เคล็ดลับที่เป็นรูปธรรมเกี่ยวกับ ensemble programming ผม ขอแนะนำให้อ่าน Ensemble Programming Guidebook ของ Maaret Pyhäjärvi ที่ตีพิมพ์เองและกระชับ 15 .