Pair Programming

สองคนทำงานร่วมกันบนงานเขียนโปรแกรมชิ้นเดียว

คืออะไร

Pair Programming หมายถึงแนวปฏิบัติที่มีคนสองคนทำงานร่วมกันบนงานเขียนโปรแกรมชิ้นเดียว บนเครื่องเดียว จอ (หรือ keyboard) เดียวกัน มันเป็นแนวปฏิบัติของ Extreme Programming (XP) และถูกใช้โดยทีมพัฒนาซอฟต์แวร์แบบ agile (และไม่ agile) จำนวนมาก แม้ในสภาพแวดล้อมดั้งเดิมที่การ pair ไม่ใช่กิจวัตรประจำวัน มันก็ยังเป็นวิธีที่หยิบมาใช้เสมอเมื่อใครสักคนเผชิญกับ bug ปัญหา หรือการตัดสินใจด้าน design ที่ยากหรือน่าหงุดหงิด ทุกครั้งที่โปรแกรมเมอร์คนหนึ่งเรียกอีกคนมาช่วยดูสิ่งที่ตนกำลังทำ นั่นคือการทำ pair programming ในรูปแบบย่อ ๆ อยู่แล้ว

Wikipedia อธิบายกลไกพื้นฐานไว้ชัดเจน คือมีบทบาทสองบทบาทที่สลับกันบ่อย ๆ ได้แก่ driver ผู้ถือ keyboard และพิมพ์ code กับ navigator (บางแหล่งเรียก observer) ผู้อ่าน code ทุกบรรทัดที่ถูกพิมพ์ พร้อมมองภาพรวมเชิงกลยุทธ์ — คิดล่วงหน้าถึงปัญหาที่จะตามมา แนวทางการออกแบบ และจุดที่ควรปรับปรุง เพื่อให้ driver มีสมาธิเต็มที่กับรายละเอียดทางยุทธวิธีตรงหน้า โดยมี navigator เป็นตาข่ายนิรภัยและเข็มทิศ Martin Fowler อธิบายเหตุผลเชิงองค์ความรู้ว่า การเขียนโปรแกรมคือการสร้างความเข้าใจใน code อย่างต่อเนื่องแล้วตัดสินใจว่าจะเปลี่ยนมันอย่างไร และคนสองคนที่ทำงานร่วมกันมักคืบหน้ากับปัญหาเช่นนี้ได้เร็วกว่าต่างคนต่างทำ เพราะ “สมองที่สอง” ที่อยู่ใกล้ ๆ ช่วยลดโอกาสที่จะหลงเข้า analytical rat-hole เสียเวลาไปหลายชั่วโมง

Pair programming ต้องมีผู้ร่วมที่ active ทั้งสองคน ไม่ใช่โปรแกรมเมอร์ที่ทำงานหนึ่งคนกับผู้สังเกตการณ์ที่เฉื่อยชาอีกหนึ่งคน หนึ่งในเงื่อนไขแรก ๆ ของการ pair ที่มีประสิทธิภาพคือการออกแบบพื้นที่ทำงานเอง โต๊ะแบบ L หรือ U หรือที่วาง keyboard และจอไว้ตรงมุมโต๊ะ ไม่เหมาะกับการ pair (หรือการทำงานร่วมกันใด ๆ) การจัดวางที่ดีที่สุดคือโต๊ะตรงที่รองรับเก้าอี้สองตัวเคียงข้างกัน พร้อมจอคู่ keyboard คู่ และเมาส์คู่ เพื่อให้โปรแกรมเมอร์คนใดก็ได้ทำงานกับปัญหาตรงหน้าได้ทุกเมื่อ โดยไม่ต้องขยับที่นั่งหรือส่ง keyboard/เมาส์ไปมา แน่นอนว่าการ pair ทำได้แม้ไม่มีสิ่งอำนวยความสะดวกเหล่านี้ครบ (เช่นในการทำงานทางไกลผ่านเครื่องมืออย่าง VS Code Live Share) แต่สภาพแวดล้อมเช่นนี้คืออุดมคติที่ขจัดแรงเสียดทานในกระบวนการไปได้เกือบหมด

ทำอย่างไร

การเริ่ม pair programming ในทีมทำได้หลายรูปแบบ ขึ้นกับเป้าหมายและระดับประสบการณ์ของคู่:

จัดที่นั่งให้เอื้อต่อการ pair จริง ๆ — โต๊ะตรง จอคู่ (หรือจอใหญ่ share กัน) keyboard/เมาส์สำรอง เพื่อสลับ driver ได้ทันทีโดยไม่มีแรงเสียดทาน
เลือกบทบาท driver/navigator แล้วสลับบ่อย — driver พิมพ์ code และโฟกัสรายละเอียดยุทธวิธี ส่วน navigator มองภาพรวม จับข้อผิดพลาด และคิดล่วงหน้า สลับบทบาททุก 15-30 นาที หรือทุกครั้งที่มี pull request/commit ย่อย
เลือกสไตล์การ pair ให้เหมาะกับสถานการณ์
- Ping-Pong pairing (นิยมคู่กับ TDD): คนหนึ่งเขียน unit test ที่ล้มเหลว (red) แล้วส่งต่อให้อีกคนเขียน code ให้ผ่าน (green) จากนั้นสลับกันเขียน test ถัดไป
- Strong-style pairing: “ความคิดใด ๆ ที่จะเข้าไปในคอมพิวเตอร์ต้องผ่านมือของอีกคนก่อน” — คนที่ navigate (มักเป็นผู้มีประสบการณ์มากกว่าหรือรู้บริบทมากกว่า) จะบอกแนวทาง ส่วน driver เป็นคนพิมพ์ตาม เหมาะกับการถ่ายทอดความรู้ให้ novice หรือคนที่เพิ่งเข้า project
- Unstructured/organic pairing: สลับบทบาทตามธรรมชาติของการสนทนา เหมาะกับคู่ที่เชี่ยวชาญใกล้เคียงกันและคุ้นเคยกันดี
สื่อสารเจตนาตลอดเวลา — driver พูดสิ่งที่กำลังคิดออกมาดัง ๆ (think aloud) navigator ถามคำถามหรือเสนอทางเลือกแทนที่จะเงียบแล้วรอวิจารณ์ทีหลัง
จำกัดช่วงเวลา pair และพักเป็นระยะ — session ยาว 2-4 ชั่วโมงพร้อมพักสั้น ๆ ช่วยรักษาสมาธิและลดความเหนื่อยล้าทางความคิด (cognitive fatigue) ซึ่งเป็นข้อจำกัดจริงของการ pair ต่อเนื่องทั้งวัน
จับคู่ให้เหมาะสมกับเป้าหมาย — ต้องการถ่ายทอดความรู้ ให้จับ senior คู่ junior; ต้องการคุณภาพ code สูงสุดสำหรับส่วนที่ซับซ้อน/เสี่ยง ให้จับ expert คู่ expert; ต้องการกระจายความเข้าใจ domain ให้สลับคู่หมุนเวียน (pair rotation) เป็นระยะ ไม่ตรึงคู่เดิมตลอดไป

flowchart LR
  Start[เริ่มงาน] --> Choose{เลือกสไตล์}
  Choose --> PingPong[Ping Pong กับ TDD]
  Choose --> Strong[Strong Style]
  Choose --> Organic[Organic Pairing]
  PingPong --> Driver[Driver พิมพ์ code]
  Strong --> Driver
  Organic --> Driver
  Driver --> Navigator[Navigator ทบทวนและคิดล่วงหน้า]
  Navigator --> Switch{ถึงเวลาสลับ}
  Switch -->|ใช่| Driver
  Switch -->|ยังไม่ถึง| Navigator
  Navigator --> Review[Commit หรือ PR ย่อย]

ตัวอย่าง

สมมติสองคนกำลัง pair แบบ ping-pong เพื่อพัฒนา method คำนวณส่วนลดใน domain คำสั่งซื้อ คนแรกเป็น driver เขียน test ที่ล้มเหลวก่อน:

// รอบที่ 1 - Alice (driver) เขียน test ก่อน (red)
public class DiscountCalculatorTests
{
    [Fact]
    public void Should_apply_ten_percent_discount_for_vip_customer()
    {
        var calculator = new DiscountCalculator();
        var result = calculator.CalculateDiscount(amount: 1000m, isVip: true);

        Assert.Equal(900m, result);
    }
}

จากนั้นสลับ keyboard ให้ Bob (ตอนนี้กลายเป็น driver) เขียน code ขั้นต่ำให้ test ผ่าน (green) โดยมี Alice ทำหน้าที่ navigator คอยตั้งคำถามเรื่องเคส edge case:

// รอบที่ 1 - Bob (driver) ทำให้ test ผ่าน
public class DiscountCalculator
{
    public decimal CalculateDiscount(decimal amount, bool isVip)
    {
        // Navigator (Alice) ถาม: "แล้วถ้า amount ติดลบล่ะ" -> บันทึกไว้เป็น test รอบถัดไป
        return isVip ? amount * 0.9m : amount;
    }
}

หลังจากนั้นสลับบทบาทอีกครั้ง Bob เขียน test ถัดไปสำหรับ edge case ที่ Alice เพิ่งเสนอ วนซ้ำแบบนี้ไปเรื่อย ๆ ทุกรอบทั้งสองคนได้ทั้งเขียน code และทบทวน code ไม่มีใครเป็นแค่ผู้ดูเฉย ๆ

ประโยชน์และข้อควรระวัง

ประโยชน์

คุณภาพ code ดีขึ้น — งานวิจัยและประสบการณ์ภาคปฏิบัติชี้ว่า code ที่ผ่านการ pair มีข้อบกพร่องน้อยกว่า เพราะมี code review เกิดขึ้นแบบเรียลไทม์ ไม่ใช่หลังเขียนเสร็จ
กระจายความรู้และลด bus factor — ความรู้เกี่ยวกับ code ไม่ได้ติดอยู่กับคนเดียว ช่วยหนุน Collective Code Ownership
ออนบอร์ดคนใหม่ได้เร็วขึ้น — strong-style pairing กับสมาชิกที่มีประสบการณ์ช่วยให้คนใหม่เข้าใจ codebase และมาตรฐานทีมได้เร็ว
โฟกัสและมี accountability สูงขึ้น — มีคนอยู่ข้าง ๆ ตลอด ลดการหลงประเด็นหรือเสียเวลาไปกับทางตัน
การตัดสินใจออกแบบดีขึ้น — การถกเถียงสด ๆ ระหว่าง driver/navigator มักนำไปสู่ทางออกที่มองครบมุมกว่าคนเดียวคิด

ข้อควรระวัง

ต้นทุนแรงงาน-ชั่วโมงสูงขึ้น — Wikipedia และงานวิจัยหลายชิ้นระบุว่า pair programming ใช้ human-hours ต่องานมากกว่าการเขียนคนเดียว แม้คุณภาพจะดีกว่า จึงควรใช้อย่างเลือกสรร ไม่ใช่บังคับทุกบรรทัด
ความเหนื่อยล้าและ intensity — การจดจ่อร่วมกันต่อเนื่องต้องใช้พลังงานสูง session ที่ยาวเกินไปโดยไม่พักจะลดประสิทธิผลลง
ความเข้ากันได้ของคู่และพลวัตอำนาจ — ถ้าคน1 dominate การสนทนาหรือ keyboard ตลอด อีกคนจะกลายเป็นผู้สังเกตการณ์เฉื่อยชา ซึ่งขัดกับหลักการที่ต้อง active ทั้งคู่ ต้องอาศัย psychological safety และวัฒนธรรมทีมที่ดี
ไม่ใช่ทุกงานที่เหมาะ — Martin Fowler เตือนว่าไม่มีเทคนิคใดเหมาะกับทุกคนหรือทุกสถานการณ์ งานสำรวจ/prototype เร็ว ๆ หรืองานที่ต้องคิดคนเดียวลึก ๆ อาจไม่เหมาะกับการ pair ตลอดเวลา
ผู้บริหารบางคนยังไม่เชื่อ — เพราะเห็นแค่ “สองคนทำงานเดียวกัน” โดยไม่เห็นคุณภาพและความรู้ที่กระจายออกไป การอธิบายด้วยตัวเลขข้อบกพร่องที่ลดลงมักช่วยโน้มน้าวได้ดีกว่าการอ้างความรู้สึก

Pair Programming

คืออะไร

ทำอย่างไร

ตัวอย่าง

ประโยชน์และข้อควรระวัง

ที่เกี่ยวข้อง

แหล่งอ้างอิง

Pair Programming

คือ​อะไร

ทำ​อย่างไร

ตัวอย่าง

ประโยชน์​และ​ข้อ​ควร​ระวัง

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง

คืออะไร

ทำอย่างไร

ประโยชน์และข้อควรระวัง

ที่เกี่ยวข้อง

แหล่งอ้างอิง