แพร์โปรแกรมมิ่ง
Pair Programming เป็นการพัฒนาซอฟร์แวร์บนคอมพิวเตอร์เครื่องเดียว ด้วยนักพัฒนาสองคน คนนึงจะเรียกว่า driver (คนขับ), และอีกคนเรียกว่า navigator (คนนำทาง) เหมือนแข่งแรลลี่
ง่ายมะ จบละ!
แต่เดี๋ยวก่อน! ไปดู “ข้อเสีย” กันก่อน
การแพร์นั้นอาจใช้เวลาในการพัฒนามากขึ้น 15–50%
อาจทำให้ผู้แพร์ฯ ไม่สบายใจ หรือมีแรงต้านระหว่างการแพร์ เพราะไม่เคยต้องสื่อสารในรูปแบบนี้กันมาก่อน
แล้วประโยชน์ของการแพร์ฯ หละคืออะไร
งานวิจัยของ Alistair Cockburn และ Laurie Williams ที่ตีพิมพ์เมือ่ปี ค.ศ. 2000 บอกว่า การแพร์ฯ นั้นสามารถลดปริมาณ defects ได้มากถึง 15%
แล้วประโยชน์ของการลด defects หละ ?! ถ้าเรามาดูค่าใช้จ่ายในการแก้ defects นั้น จากรายงานของ IBM ที่ต้องแก้ปัญหาจำนวน 30,000 ปัญหา ใช้เงินในการแก้ไข และติดตั้งใหม่ประมาณ 250 ล้าน USD ซึ่งเท่ากับ 8,000 USD ต่อ 1 ปัญหาที่รายงานเข้ามา
เมื่อหักลบกับข้อเสีย
ในรายงานของ IBM บอกว่าต่อหนึ่ง defect นั้นใช้เวลามากถึง 33–80 ชั่วโมง โดยแบ่งเป็นการทดสอบระดับ system test จาก QA 4–16 ชั่วโมง แล้วถ้ามีทั้งหมด 225 ต้องใช้เวลามากถึง 9,000 ชั่วโมง ซึ่งมากกว่าเวลาที่เสียไปในแพร์ฯ ถึง 60 เท่า
หลังจากที่นักเรียนจำนวนหนึ่งในงานวิจัยนี้ได้แพร์กันแล้ว เขาชอบการแพร์ฯ หรือไม่
จากการทดสอบในช่วงแรกนั้นอาจจะรู้สึกแปลก ๆ หรือมีแรงต้านอยู่บ้าง เพราะต้องออกจาก comfort zone ที่เคยเขียนโปรแกรมคนเดียวมาตลอด แต่มันก็เหมือนกับการกินของเผ็ด แรก ๆ อาจจะไม่ชอบ แต่พอได้กินมากขึ้นเรื่อย ๆ ก็จะยิ่งติดใจความเผ็ด
จากผลการสำรวจนักเรียนประมาณ 80% หรือมากกว่าในแต่ละรุ่น พึงพอใจในการแพร์ฯ
แต่ผลการทดสอบนี้อาจมีความเอนเอียง เพราะในช่วงแรกนั้นได้แบ่งนักเรียนเป็น 2 กลุ่ม กลุ่มนึงให้ทำงานคนเดียวตลอด อีกกลุ่มนึงให้ทำกันเป็นคู่ ซึ่งทำให้นักเรียนที่ต้องทำงานคนเดียวคิดว่าไม่ยุติธรรม หลังจากแจกงานกันไปทำได้สองสามรอบ เนื่องจากคนเดียวต้องทำงานหนักกว่าสองคนช่วยกันอยู่แล้ว นี่อาจส่งผลต่อผลคะแนนว่าชอบการแพร์ฯ ก็เป็นได้
การแก้ปัญหา การเรียนรู้
ในการเขียนโค้ดนั้นบางครั้งพอเราทำคนเดียวพอติดก็จะติดนานมาก แต่พอเราหันไปถามอีกคนข้าง ๆ เราได้คำตอบก่อนที่จะถามจนจบด้วยซ้ำ ซึ่งการแพร์ฯ จะช่วยเราก่อนที่เราจะติดหล่มอยู่คนเดียวเสียอีก
การแพร์ฯ นั้นทำให้เราได้แบ่งปันประสบการณ์ และมุมมอง ของกันและกัน บ่อยครั้งที่เรามีข้อมูลไม่เท่ากัน และตัดสินใจผิดพลาด ซึ่งการแพร์ฯ จะช่วยลดความผิดพลาดที่จะเกิดขึ้นได้
ทำให้นักพัฒนาต้องฝึกการสื่อสารระหว่างกัน ใช้กิริยา ท่าทาง น้ำเสียง คำพูด และนี่ก็อาจจะเป็นจุดเริ่มต้นที่ดีที่จะพัฒนาต่อไปถึงการสื่อสารกับลูกค้ามากกว่าการสื่อสารกับคอมพิวเตอร์ผ่านคีย์บอร์ด
คุณภาพของผลงาน
ในงานผลการศึกษาที่มหาวิทยาลัยยูทาห์พบว่าการแพร์ฯ นั้นจะผลิตบรรทัดของ code น้อยกว่าการเขียนคนเดียว ซึ่งอาจจะเป็นสัญญาณของการออกแบบที่ดีกว่า
แพร์จะเปิดโอกาสให้เราแบ่งปันวิธีการเขียนโค้ดในรูปแบบที่ต่างออกไป ฟีเจอร์ใหม่ ของภาษา หรือฟีเจอร์ที่มีอยู่แล้ว ไม่ต้องสร้างใหม่มาซ้ำกับของเดิม
มีการถกเถียงถึงวิธีการแก้ปัญหา ซึ่งอาจมีหลายวิธีการถูกกางขึ้นมาระหว่างการแพร์ฯ และเลือกวิธีการที่ดีที่สุด ณ ขณะนั้น ซึ่งดีกว่าเลือกคนเดียว เพราะการเลือกคนเดียวบางครั้งอาจปิดกั้นวิธีการอื่น ๆ ที่เขามา เพราะบางครั้งเราจะเลือกวิธีการแรกที่เราคิดได้ และไม่เปิดรับวิธีการอื่น ๆ ซึ่งอาจจะดีกว่า
เกิดการรีวิวโค้ดอย่างต่อเนื่อง ระหว่างการทำงานทุกตัวอักษร ซึ่งบางครั้งได้ผลลัพธ์ที่ดีกว่าการตามมารีวิวทีหลัง
ร่วมกันสร้างสรรค์
แม้จะเล็ก ๆ น้อย เช่นการสะกดผิด เว้นวรรคผิด กำลังหลงทางว่าตอนนี้ทำอะไรอยู่ ต้องทำอะไรต่อ ก็จะมีคนข้าง ๆ คอยดึงสติให้กลับมาที่เดิม
ข้อควรระวัง
- ไม่ออกนอกเรื่อง การคุยกับเรื่องปรัชญา หรือชีวิต คำตอบของจักรวาลและทุกสรรพสิ่ง จะทำให้เราหลุดจากสิ่งที่ทำอยู่ และอาจลามไปถึงคนข้าง ๆ ในทีมที่จะมาร่วมวงสนทนาด้วย
- เล่นโทรศัพท์ ตอบแชท เชคเมล สนใจสิ่งที่อื่น ไม่สนใจคู่แพร์ หรือสิ่งที่กำลังทำกันอยู่
- หายตัวไปทำอย่างอื่น
- ขโมยคีบอร์ด หรือเมาส์อีกคนหนึ่ง
- แพร์ฯ แต่กับคนเดิม ๆ ไม่ยอมเปลี่ยนคู่แพร์
- เผด็จการ สั่งให้ทำแบบนั้น แบบนี้ตลอดเวลา อาจทำให้คู่แพร์ไม่สบายใจ ถ้าเรายังแก้ไม่ได้การบอกเหตุผลว่าทำแบบนั้นแบบนี้ไปทำไมจะช่วยได้ดีขึ้น
- พี่วอร์มแนะนำว่าก่อนเริ่มแพร์ฯ ให้เราตกลงกับหัวหน้าให้เรียบร้อยก่อนนะ 🤣
ถ้าใครได้ลองแล้วถูกใจติดใจไม่ชอบใจตรงไหน สามารถแชร์กันได้นะครับ
ถ้าไม่รู้จะเริ่มแพร์ยังไงลองเริ่มแบบ https://medium.com/@phai/f81fb27d6c1e ก็ได้
สวัสดีครับ