eXtreme Programming

• เป็นเรื่องที่สนใจนะสมัยเรียน เคยได้ยินคำนี้อ่ะ
• แต่ไม่ค่อยได้หาข้อมูลสักเท่าใหร่
• ไปเจอบล็อคนี้เค้าอธิบาย โอเคเลยเขียนไว้เมื่อ 2005 ค่อนข้างเก่า
• ขอบคุณเจ้าของบทความมา ณ ที่นี้ด้วยครับ
  

Extreme Programming (XP) ถือกำเนิดขึ้นช่วงประมาณปี 1990 มีชายผู้หนึ่งนามว่า Kent Beck พยายามคิดค้นวิธีที่จะสร้างโปรแกรมดีๆ ออกมา (และ bug น้อยๆ) ก็ได้ช่วยกันคิดกับเพื่อนอีกคนคือ Ward Cunningham ว่าอยากให้มันเป็นแนวความคิดที่ง่ายๆ แต่มีประสิทธิภาพสูง ใครๆ ก็สามารถทำได้ จึงร่วมกันทำโปรเจ็คอันนึงและก่อให้เกิดการโปรแกรมแบบ Extreme Programming ขึ้นมา

การเขียนโปรแกรมโดยถือทางแบบ XP นี้ มีหลักการย่อยๆ อยู่นิดเดียว

1. Pair Programming ก็คือการเขียนโปรแกรมเป็นคู่หรือเป็นกลุ่มนั่นเอง (แต่เป็นกลุ่มคงทะเลาะกันตาย เป็นคู่ดีกว่าเนอะ)
2. Test-Driven Development ซึ่งคือ การเขียนโปรแกรมโดยมีการ test ก่อนโปรแกรมทีหลัง (ฟังแล้วงงๆ)

การ ทำ pair-programming จะมีผลดีในแง่ที่ว่า จะช่วยลดความผิดพลาดง่ายๆ ที่อาจเกิดขึ้นจากการโปรแกรมคนเดียว (เคยป่าว คิดอะไรคนเดียวแล้วเดินทางผิดมาตลอด เจ้าตัวเองยังไม่รู้) ป้องกันการมองอะไรด้านเดียวและความไม่รอบคอบ จะทำให้การทำงานมีประสิทธิภาพมากขึ้น แต่ทั้งนี้ทั้งนั้น การทำ pair-programming นั้นต้องใช้ resource เยอะในช่วงแรกๆ แน่นอนว่าตอน pair กันใหม่ๆ งานจะกระดึ๊บๆ เดินช้ามากกกก.. แต่เมื่อทั้งสองคนจูนกันติดแล้ว การทำงานจะเร็วขึ้น มองอะไร เข้าใจไอเดียของกันและกันได้เร็วขึ้น (ถ้าไม่ตีกันตายไปซะก่อน) งานช่วงหลังๆ ก็จะเร็วขึ้นติดจรวด

ลอง คิดดูว่า ถ้าเราโปรแกรมคนเดียว คิดคนเดียว ออกแบบคนเดียว ต่อให้เดินทางมาผิด เราก็จะไม่รู้ว่าผิดตั้งแต่ตรงไหน และจะไม่รู้จนกระทั่ง เราเจอทางตันหรือ error ตัวแดง สิ่งที่จำใจต้องทำก็คือ การรื้อโค้ด การแก้ แก้ แก้ แก้ จนโค้ดมันเริ่มมั่ว แก้ตรงนั้น กระทบตรงนี้ สรุป.. ก็ต้องใช้เวลาแก้นานอยู่ดี --"-- การทำ pair-programming จะช่วยให้ลดความเสี่ยงตรงนี้ลงได้มากทีเดียว

อีก สิ่งหนึ่งที่ควรทราบคือ การโปรแกรมโดยใช้หลักการ Test-driven development (TDD) เป็นการโปรแกรมโดยมีการทำ test เป็นสิ่งที่ช่วยนำไปสู่เป้าหมายที่เรากำหนด (abstract จัง อ่านเองยังไม่รู้เรื่อง) มีคนให้คำจำกัดความโปรแกรมที่ใช้วิธี TDD เขียนว่า CLEAN CODE THAT WORKS ความหมายก็ตรงตัว คือ โปรแกรมที่เรียบง่ายและทำงานได้สมบูรณ์ วิธีการเขียนโปรแกรมแบบ TDD มีหลักการดังนี้

เมื่อเราลิสต์สิ่งที่เราต้องการออกมา (interface, features, functions/methods,...)

1. เขียนเทสต์ออกมาเพื่อที่จะเทสต์สิ่งที่อยู่ในลิสต์ (ทีละอันก่อน)
2. compile/run โปรแกรมและมันก็จะเทสต์ไม่ผ่าน (ก็ยังไม่ได้เขียนอะไรเลยอ่ะ ผ่านก็ผีหลอกแล้ว)
3. เขียนโค้ดง่ายๆ เข้าไป (เน้นว่าง่าย) ถ้าเป็น function จะ return ค่าคงที่หรืออะไรก็ได้เข้าไปก่อนก็ได้ ขอแค่ให้ test ผ่านก็พอ
4. จากนั้นก็ run โปรแกรมซึ่งก็ควรจะผ่าน
5. กลับไปดู function หรือโค้ดใดๆ ที่เพิ่งแก้ไปในข้อ 3 เขียนมันให้สมบูรณ์แล้วจึง compile ใหม่ (และก็ควรจะผ่าน) ถ้ามันเป็น function ที่ซับซ้อนมากนัก ก็แตกออกมาให้ย่อยลงมาอีกหน่อย จากนั้นก็ย้อนกลับไปทำที่ข้อ 1 โดยก้าวไปสู่ข้อที่ 2 ในลิสต์ของเราที่ทำไว้

สมมติว่าเราจะเขียนโปรแกรมเครื่องคิดเลขง่ายๆ ขึ้นมา แค่บวก ลบ คูณ หารได้ก็พอ อย่างแรกที่ต้องทำคือเขียนเทสต์

public class MyApp() {
public MyApp() {
plus(1,2);
}
}

จาก ข้างบน เราเริ่มจากเขียนเรียก interface ที่เราอยากมี(เมื่อโปรแกรมเสร็จ) และก็ compile ซึ่งก็จะไม่ผ่านเพราะมันไม่มี method Plus() ซักหน่อย --"-- ก็ทำตามข้อ 3 เขียนโค้ด

public class MyApp() {
public MyApp() {
plus(1,2);
}

public plus(int i, int j) {
return 0;
}
}

ใส่ function นั้นเข้าไปแล้ว return อะไรซักอย่างออกมาก่อนก็ได้ compile ผ่านและกลับไปเขียนโค้ดให้สมบูรณ์ ได้ออกมาเป็นว่า

public class MyApp() {
public MyApp() {
plus(1,2);
}

public plus(int i, int j) {
int sum = 0;
sum = i + j;
return sum;
}
}

ก็ จะเป็นการสมบูรณ์(ในระดับหนึ่ง)สำหรับ method Plus() หาต้องการให้มันเช็ค null หรือค่าอะไรได้มากกว่านี้ก็ทำการเพิ่มเทสต์เข้าไปและเริ่มต้นวงจรใหม่ที่ข้อ 1 ทำอย่างนี้ไปเรื่อยๆ จนทำ feature ต่างๆ ในลิสต์จนครบ การเขียนเทสต์ย่อยๆ ขึ้นมาแต่ละข้อนั้น ก็ทิ้งไว้และเขียนเพิ่มไปเรื่อยๆ จนกว่าคิดว่าเทสต์ข้อนั้นไม่จำเป็นต้องมีแล้วหรือเป็นการเทสต์ซ้ำกับข้ออื่น ก็ให้ลบได้

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

ตัวอย่าง ที่เคยอ่านจากหนังสือของ Kent Beck ชื่อหนังสือ Test-Driven Development ตรงตามตัวเลย เค้ามีตัวอย่างการเขียนจากไม่กี่บรรทัดอย่างที่ยกตัวอย่างให้ดู เขียนไปเรื่อยๆ จนสร้าง super class สร้างinterface สร้างอะไรต่างๆ เป็นเรื่องเป็นราว สิ่งที่คนใช้ TDD ควรรู้เป็นอย่างดีก็ได้แก่การทำ OOP และหลักการ programming ต่างๆ ทั้งหลายนั่นเอง (อันนี้แหละที่ย๊ากยาก) ดังนั้น การทำ TDD จึงควรทำเป็น pair-programming ด้วย (ลำพังเดี๊ยนคนเดียว ไปไม่รอดแน่)

ข้อดีมากๆ ของการทำ XP คือนั่นแหละ CLEAN CODE THAT WORKS โปรแกรม ที่ใครอ่านก็เข้าใจง่าย (เกิดใครมาเอาไปทำต่อ จะได้ไม่งงตาแตก) และทำงานได้ตรงอย่างที่เราต้องการอยากให้ทำ การทำ TDD จะเป็นการออกแบบโปรแกรมออกมาในเชิง Top-Down คือ design ออกมาจากผลลัพธ์ที่เราอยากจะได้ สิ่งที่ได้ออกมาก็จะตรง requirement มากกว่า และโค้ดก็จะไม่รกรุงรัง

ที่มา: http://nongtik.exteen.com/20051018/extreme-programming