TDD, AI Agents and Coding - Kent Beck

แนะนำ Kent Beck

• ผู้ก่อตั้ง Extreme Programming (XP)
• ผู้ร่วมเขียน Agile Manifesto (ผู้ลงนามคนแรกตามลำดับตัวอักษร)
• ผู้บุกเบิก TDD (Test-Driven Development)
• ตำนานของวงการที่มีประสบการณ์เขียนโค้ด 52 ปี
• ปัจจุบันกำลังเขียน "Tidy Together" (การออกแบบซอฟต์แวร์และการทำงานเป็นทีม)
• เขียนโค้ดด้วยเครื่องมือ AI วันละ 6-10 ชั่วโมงขึ้นไป และกำลังอยู่ในช่วง "เวลาที่สนุกกับการเขียนโปรแกรมที่สุด"

---

1. เครื่องมือเขียนโค้ดด้วย AI และอุปมาเรื่อง 'ยักษ์จีนี่'

แนวคิดสำคัญ: จีนี่ที่คาดเดาไม่ได้

• เปรียบ AI agent ว่าเป็น "จีนี่ที่คาดเดาไม่ได้"
• "มันไม่ได้ทำสิ่งที่ฉันหมายถึงได้อย่างแม่นยำ"
• "พวกมันมีวาระของตัวเอง"

ประสบการณ์การทำงานร่วมกับ AI

ด้านบวก:

• บางครั้งช่วยแก้ปัญหาด้านดีไซน์ใหญ่ ๆ ได้ราวกับเวทมนตร์
• สร้างฟีเจอร์ที่มีประโยชน์แบบไม่คาดคิด (เช่น B+ tree stress tester)

ด้านลบ:

• ตีความเจตนาของผู้ใช้ผิด
• พยายามลบหรือแก้ไขเทสต์
• มีพฤติกรรมกวน ๆ อย่างพยายาม "แก้" ปัญหาด้วย lookup table

ประสบการณ์ที่ชวนให้ติด

• รางวัลเป็นช่วง ๆ แบบสล็อตแมชชีน
• "เดินผ่านคอมพิวเตอร์ตอนกลางคืนแล้วคิดว่า 'ลอง prompt อีกสักครั้งดีไหม?'"
• "เริ่ม prompt ที่ใช้เวลาหนึ่งชั่วโมงแล้วออกไปข้างนอก"

---

2. การเปลี่ยนแปลงของทักษะในยุค AI

การจัดระเบียบคุณค่าของทักษะใหม่

"ทักษะ 90% หมดคุณค่าไป และอีก 10% มีมูลค่าเพิ่มขึ้น 1000 เท่า"

ทักษะที่มีมูลค่าเพิ่มขึ้น:

• การกำหนดวิสัยทัศน์
• การจัดการหมุดหมายสำคัญ
• การควบคุมความซับซ้อน

ทักษะที่มีมูลค่าลดลง:

• รายละเอียดเฉพาะของแต่ละภาษา (เช่น ตำแหน่งของ &, *, [] ใน Rust)

มุมมองต่อภาษาโปรแกรมที่เปลี่ยนไป

อดีต: ผูกพันทางอารมณ์กับ Smalltalk อย่างลึกซึ้ง
ปัจจุบัน:

• "เจ็บมามากเกินไป" จนเลิกยึดติดกับภาษาแล้ว
• เหนื่อยกับการแบ่งตัวตนว่าเป็น "Java developer", "Clojure developer"
• "การเรียนรู้แบบออสโมซิส": ด้วย AI ทำให้เขียนโปรแกรมได้แม้ไม่รู้รายละเอียดของภาษามากนัก

ภาษาที่ลองใช้ล่าสุด: Swift, Go, Rust, Haskell, C++, JavaScript

โปรเจกต์ที่ทะเยอทะยานในปัจจุบัน: Server Smalltalk

• persistent: ทำงานเหมือนฐานข้อมูล
• transactional: สามารถ commit และ abort ได้
• parallelism: ประมวลผลแบบขนานได้ทั้งหลายเธรดและข้ามหลายเครื่อง
• รองรับการจัดการ ข้อมูลขนาดใหญ่

---

3. ประวัติของ Agile Manifesto

ที่มาของการถือกำเนิด (ปี 2001)

• ค้นหาทางเลือกแทน waterfall model
• เป็นผลลัพธ์จากเวิร์กช็อปด้านวิธีวิทยาซอฟต์แวร์ที่จัดต่อเนื่องมาหลายปี
• เริ่มจากการประชุมเตรียมตัวสำหรับทริปล่องเรือในนอร์เวย์ → ก่อนจะไปประชุมสรุปที่ยูทาห์

สิ่งที่ Kent Beck มีส่วนร่วม

• เพิ่มคำว่า "daily" (ในหลักการ 12 ข้อ ส่วน "ปฏิสัมพันธ์กันทุกวัน")
• เป็นผู้ลงนามคนแรกตามลำดับตัวอักษร

ความไม่พอใจต่อคำว่า "Agile"

ปัญหา:

• คำนี้ "ฟังดูดึงดูดเกินไป" จนคาดได้ว่าองค์กรทุกแห่งจะหยิบไปใช้พร่ำเพรื่อ
• จึงเกิดองค์กรที่อ้างว่าตัวเองทำ Agile ทั้งที่ไม่ได้ทำตามหลักการจริง

คำทางเลือกที่ชอบกว่า: "conversational(เชิงสนทนา)"

• เน้นการสื่อสารสองทาง ไม่ใช่ทางเดียว
• แต่ไม่ได้รับเลือกเพราะไม่ดึงดูดพอ

---

4. Extreme Programming (XP)

ที่มาของการก่อตั้ง

ประสบการณ์ช่วงแรกในการเป็นที่ปรึกษา:

• ตอนแรกเป็นที่ปรึกษาเชิงเทคนิค (performance tuning, bit manipulation)
• ต่อมาถูกขอคำแนะนำด้านการบริหารโปรเจกต์มากขึ้น
• ค้นพบความสำคัญของสภาพแวดล้อม: แค่เปลี่ยนผังที่นั่งก็ทำให้ดีขึ้นอย่างมาก

โปรเจกต์ Chrysler:

• พลิกโปรเจกต์ที่กำลังล้มเหลวให้กลับมาสำเร็จ
• ดันทุกแนวปฏิบัติที่ได้ผลให้ไปถึงระดับ "สูงสุด(11)"

หลักการสำคัญของ XP

แบ่งเวลาให้ย่อยลง แล้วทำ 4 กิจกรรมนี้ไปพร้อมกัน/ต่อเนื่องกัน:

1. ทำความเข้าใจว่า จะทำอะไร
2. ออกแบบว่า จะจัดโครงสร้างอย่างไร
3. ลงมือสร้างฟังก์ชัน
4. ตรวจสอบว่าทำงานตามที่คาดหรือไม่

Pair Programming

• เป็นแนวทางแบบทดลอง ไม่ใช่ข้อบังคับ
• ประสบการณ์ทีมช่วงแรก: บั๊กทั้งหมดที่พบหลังพัฒนาเกิดจากโค้ดที่ทำคนเดียว
• "ถ้า pair programming จะไม่มี production defect เลย"

กลยุทธ์ในการตั้งชื่อ

• เหตุผลที่เลือกคำว่า "Extreme": เป็นชื่อเชิงยั่วยุที่คู่แข่ง (Grady Booch) ไม่น่าจะใช้
• จังหวะพอดีกับยุคที่กีฬา extreme กำลังเป็นกระแส
• "นักกีฬา extreme เตรียมตัวมาดีที่สุด ไม่งั้นก็ตาย" - เป็นอุปมาที่ดี

ปัจจัยแห่งความสำเร็จ

• ในช่วงฟองสบู่ดอตคอม แนวทางนี้ดึงดูดนักพัฒนาที่สิ้นหวังกับ waterfall แบบ 18 เดือน
• สัญญาว่าจะได้ผลลัพธ์ที่ เร็วกว่าและคาดการณ์ได้มากกว่า

---

5. Test-Driven Development (TDD)

จุดกำเนิดและแรงบันดาลใจ (ทศวรรษ 1970)

ระบบ tape-to-tape:

• เจอแนวคิดนี้จากหนังสือเขียนโปรแกรมของพ่อ
• พิมพ์อินพุตจริง → พิมพ์เอาต์พุตที่คาดหวังด้วยมือ → เขียนโค้ด → เปรียบเทียบกับเอาต์พุตจริง
• อ่านตอนอายุ 8-12 ปี แต่ตอนนั้นยังไม่เข้าใจ

การพัฒนา S-Unit:

• พัฒนาขึ้นเพื่อช่วยลูกค้าเขียนเทสต์
• ลองไอเดียที่ดู "เหลือเชื่อ" ว่า "ใส่ค่าที่คาดหวังก่อนเขียนโค้ด"

ประสบการณ์ TDD ครั้งแรก: การทำ stack

บุคลิกที่ขี้กังวล:

• "ฉันเป็นคนขี้กังวล กังวลไปหมด"
• "การเขียนโปรแกรมเป็นแหล่งกำเนิดความกังวลอย่างต่อเนื่อง" (ลืมอะไรไปไหม? ทำอะไรพังไปหรือเปล่า?)

ผลลัพธ์เมื่อใช้ TDD:

• "ความกังวลหายไปหมดเลย"
• "ฉันมั่นใจว่าสิ่งนี้ทำงานได้"
• ประสบการณ์ทางอารมณ์ของการเขียนโปรแกรมเปลี่ยนไป

คุณค่าของ TDD

ข้อดีเชิงเทคนิค:

• ลดความหนาแน่นของ defect
• ได้ feedback เร็วเรื่องการเลือก API
• เปิดทางให้ดีไซน์ของ implementation พัฒนาต่อได้

ข้อดีเชิงอารมณ์:

• "แค่ค่ายาแก้อาการ tech anxiety ก็ถือว่าคุ้มแล้ว"

คำโต้แย้งเรื่องการออกแบบ

คำวิจารณ์ของ John Osterhout: "TDD ไม่ช่วยเรื่องดีไซน์ มันพาไปสนใจแต่รายละเอียด"

คำตอบโต้ของ Kent Beck:

• "มันเป็นเรื่องของการเลือก"
• ผู้ปฏิบัติจริงจะ สลับขึ้นลงระหว่างหลายระดับของ abstraction อยู่ตลอด ขณะตัดสินใจด้านดีไซน์
• ช่วง "คลายความตึงเครียด" ในวงจร Red-Green ช่วยให้มีอิสระในการคิดเรื่องดีไซน์ที่ใหญ่ขึ้น

---

6. AI agents และ TDD

การประยุกต์ใช้ในการทำงานจริง

เขียนเทสต์ก่อนเสมอ:

• ใช้เทสต์สื่อสารสิ่งที่ AI มองข้าม
• ป้องกันไม่ให้ AI พยายามแก้หรือลบเทสต์

สิ่งที่ยังจำเป็นต้องมี:

• ต้องการ "immutable annotation"
• "อันนี้ถูกต้อง อย่าไปแตะมัน ไม่งั้นจะตื่นอยู่ในความมืดตลอดกาล"

ข้อจำกัดของ AI

• ยังลด coupling / เพิ่ม cohesion ได้ไม่เก่ง
• ขาดเซนส์ด้านดีไซน์
• มีแนวโน้มตัดสินใจแบบ ส่งผลกระทบไกลเป็นลูกโซ่

กลยุทธ์รับมือ

• ชุดทดสอบขนาดใหญ่ที่รันได้ใน 300 มิลลิวินาที
• ตรวจจับการทำโค้ดพังโดยไม่ตั้งใจของ AI ได้แบบเรียลไทม์

---

7. ประสบการณ์ที่ Facebook (2011-2017)

ช็อกเมื่อเข้าร่วมในปี 2011

คนเข้าคลาส TDD เป็นศูนย์:

• เทคนิค Excel ขั้นสูง: เต็ม + มี waiting list
• Argentine Tango: เต็ม + มี waiting list
• TDD: ไม่มีผู้เข้าร่วม

กลยุทธ์รับมือ:

• "ลืมความรู้วิศวกรรมซอฟต์แวร์ทั้งหมดไปก่อน"
• ตัดสินใจ "ดูแล้วทำตามแบบลิง"

สภาพแวดล้อมการพัฒนาที่เป็นเอกลักษณ์ของ Facebook

ความรับผิดชอบที่เข้มข้น:

• โปรแกรมเมอร์เป็นคนที่ถูกเรียกตอนกลางคืน
• "ได้รับความเจ็บปวดจากความผิดพลาดของตัวเองโดยตรง"

วงจร feedback หลายชั้น:

• development server ที่เร็วมาก (เปลี่ยนจากสีน้ำเงิน→สีเขียวแล้วเห็นผลทันที)
• code review
• internal deployment (พนักงานใช้ทั้งเรื่องส่วนตัวและงาน)
• ทยอย rollout (รายวัน/รายสัปดาห์)
• observability ที่ยอดเยี่ยม

วัฒนธรรมองค์กร:

• "ที่ Facebook ไม่มีอะไรเป็นปัญหาของคนอื่น"
• ต่อให้คุณยายเดินมาบอกว่าหลานโดนรังแก ก็ "นั่นก็เป็นปัญหาของคุณเหมือนกัน"

เหตุผลที่ TDD ไม่เหมาะ

ขอบเขตของปัญหาจริง:

• ปัญหาเรื่อง configuration
• ความสัมพันธ์ระหว่าง subsystem
• สิ่งที่จับด้วยเทสต์ได้ยาก

ข้อได้เปรียบเฉพาะของ Facebook:

• การทดสอบขนาดใหญ่แบบ live กับผู้ใช้หลายล้านคน
• observability ที่ยอดเยี่ยม
• Feature Flag
• เป็นสภาพแวดล้อมที่บริษัททั่วไปทำตามได้ยาก

กรณีตัวอย่าง:

• ทำฟีเจอร์สถานะความสัมพันธ์ (จากโสด/แต่งงาน เพิ่ม civil union/อยู่กินกัน)
• ใช้ TDD แต่ "เสียเวลาเปล่า"
• เกิดปัญหาจาก implicit coupling ในโค้ดแจ้งเตือน → คนอื่นมาทำ hotfix

การเปลี่ยนแปลงตามช่วงเวลา

ปี 2011 (2,000 คน):

• ศักยภาพ ขนาด และความเป็นเจ้าของงาน สูงมาก
• มีผู้จัดการระดับกลางที่คิดเรื่อง global optimization
• ร่วมมือกันโดยคิดว่า "ใครคือคนที่ต้องการความช่วยเหลือจริง ๆ"

ปี 2017 (15,000 คน):

• การเมือง แนวคิดแบบ zero-sum และการ optimize แบบจุดย่อย
• วาดภาพใหญ่ได้ยากขึ้น
• ผลประโยชน์ระหว่างแผนกขัดกัน (เช่น ทีมบทความยาว vs ทีม optimize like/comment)

ประสบการณ์กับสเกล

• Messenger API: เรียกใช้งาน 1 quadrillion ครั้งต่อสัปดาห์
• กลุ่มทดลองมีขนาดระดับ "นิวซีแลนด์" (หนึ่งล้านคน)
• 1 quadrillion = หนึ่งล้าน × หนึ่งพันล้าน

---

8. อนาคตของการพัฒนาซอฟต์แวร์ในยุค AI

การเปลี่ยนพาราไดม์

โครงสร้างต้นทุนถูกจัดระเบียบใหม่ทั้งหมด:

• "เส้นแบ่งระหว่างของถูกกับของแพงเปลี่ยนไปหมดแล้ว"
• สิ่งที่เคยถูกมองว่าแพง กลับกลายเป็น "ถูกอย่างเหลือเชื่อ"

โจทย์เรื่องการปรับตัวขององค์กร

ต้องทิ้งโค้ดให้มากขึ้น:

• สร้างอาร์ติแฟกต์ได้มากขึ้น 10 เท่า
• แต่สุดท้ายก็ยังมีแค่ หนึ่งชิ้นที่มีคุณค่า
• จำเป็นต้องมีระบบให้รางวัลกับ "การทิ้งการทดลองที่เสร็จแล้ว"

ปริมาณการทดลองที่เพิ่มขึ้น:

• จำนวนไอเดียที่ได้สำรวจ จะเป็นความได้เปรียบในการแข่งขัน
• เป็นยุคที่ต้อง "ลองทดลองทุกอย่าง"

การเปลี่ยนแปลงส่วนตัว

• การเขียนโค้ดกลับมาสนุกอีกครั้ง
• ทำให้มี ความทะเยอทะยานมากขึ้น
• ทำให้ "ความคิดที่ทะเยอทะยานสุด ๆ" กลายเป็นจริงได้

---

9. Q&A สั้น ๆ

ความชอบส่วนตัว

• ภาษาที่ชอบที่สุด: Smalltalk
• ภาษาที่สอง: JavaScript (คล้าย Smalltalk)
• เครื่องมือ AI ที่ใช้อยู่ตอนนี้: Claude (เอนจินภายในของ Cursor, Augment)
• หนังสือแนะนำ: "The Timeless Way of Building" by Christopher Alexander

---

ข้อสังเกตสำคัญ

1. ความสำคัญอย่างยิ่งของบริบท

• วิธีวิทยาเดียวกันให้ผลต่างกันโดยสิ้นเชิงตามสภาพแวดล้อม
• สภาพแวดล้อมขนาดใหญ่ของ Facebook vs สภาพแวดล้อมธุรกรรมขนาดเล็กของธนาคาร

2. ความสัมพันธ์ระหว่างอารมณ์กับเทคโนโลยี

• คุณค่าที่แท้จริงของ TDD คือ "การลดความกังวล"
• การเปลี่ยนแปลงทางอารมณ์ สำคัญกว่าตรรกะเชิงเทคนิค

3. วิธีคิดใหม่ในยุค AI

• วิสัยทัศน์และความสามารถด้านดีไซน์ กำลังกลายเป็นทักษะหลัก
• รายละเอียดของภาษาไม่สำคัญอีกต่อไป
• ปริมาณของการทดลองที่เพิ่มขึ้น จะเป็นความได้เปรียบในการแข่งขัน

4. พลังของวัฒนธรรมองค์กร

• "ไม่มีอะไรเป็นปัญหาของคนอื่น" คือความเป็นเจ้าของที่แท้จริง
• ความต่างระหว่าง global optimization vs การ optimize เฉพาะตัว
• ความสำคัญของ การจัดแรงจูงใจให้สอดคล้องกัน

[mse9000]

สภาพแวดล้อมการพัฒนาที่เป็นเอกลักษณ์ของ Facebook
ความรับผิดชอบที่เข้มข้น:
โปรแกรมเมอร์เป็นผู้ถูกเรียกตอนกลางคืน
"รับรู้ความเจ็บปวดจากความผิดพลาดของตัวเองโดยตรง"

นี่ก็ไม่ได้ต่างจากสภาพแวดล้อมการพัฒนาแบบ K มากนัก...?

[helloppfm]

ยังอยู่ตรงนี้นะครับ

เมื่อก่อนเคยไปสัมมนาเรื่อง TDD ที่บริษัทเครื่องจักรแห่งหนึ่ง แต่ยังจำสายตาที่ทุกคนมองประมาณว่า "นี่คืออะไร?" ได้ไม่ลืม

ผมคิดว่า TDD ก็ดีนะ แต่กลับทำได้ไม่ค่อยดีอย่างที่คิด...
เลยทำ integration test แบบเดียวกับ TDD อยู่ครับ แน่นอนว่านี่ไม่ใช่ TDD ^^

[kandk]

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

[codemasterkimc]

เป็นบทความที่ดีนะครับ