อีกหนึ่งในทางเลือกของการการพัฒนา Application ที่ยึดหลักง่ายๆ 4 อย่างด้วยกันคือ simplicity, communication, feedback and courage
Simplicity: ทำทุกอย่างให้ง่ายที่สุด ปรัชญาการเขียนโปรแกรมแบบ KISS (Keep It Simple and Sequential) คือหัวใจของการพัฒนาโปรแกรมแบบ XP. ให้นำหลักการนี้ไปใช้กับทุกๆ ส่วนของโปรแกรม
Communication: การสื่อสาร ตีความได้หลายๆทาง สำหรับโปรแกรมเมอร์คือการ coding ที่ดี comment ที่ดี แต่!! การเขียนโค๊ดที่อธิบายตัวมันเอง(Self-documenting) อยู่แล้วดีที่สุด (การตั้งชื่อ Method, Variable ที่สื่อความหมาย ไม่ควรตั้งชื่อตัวแปรแบบลอยๆ เช่น int x int y) การทำ unit test ก็เป็นอีกทางหนึ่งในการควบคุมการสื่อสารให้ตรงกัน (แก้ไขโค๊ดยังไงก็ต้องได้ผลลัพธ์เหมือนเดิม)
Feedback: มีวงจรการพัฒนารอบละสั้นๆ เพื่อให้ลูกค้าได้ทำการตรวจสอบ ให้ตรงตามความต้องการและที่user พึงพอใจ เพื่อไม่ให้มีการเสียเวลาในการปรับ requirement ที่มีการพัฒนามานานโดยที่ userไม่เคยเห็น Application จริงเลย แล้วไม่พอใจหลังจากทำการส่งมอบ ต้องเสียเวลาในการแก้ไข ในบางครั้งอาจจะถึงขั้นต้อง แก้ไขทั้ง module เป็นต้น (ขั้นตอนนี้เหมือนกับการพัฒนาโปรแกรมแบบ Agile )
Courage: ความกล้าที่จะเปลี่ยนแปลง โดยเฉพาะหลักการ pair programming ที่ดูเผินๆแล้วจะเหมือน productivity จะหายไปครึ่งหนึ่ง เพราะใช้โปรแกรมเมอร์ถึงสองคนในการทำงานเดียวกัน อีกทั้งการพัฒนาโปรแกรมแบบ Simplicity ที่อาจจะฝืนความรู้สึกของโปรแกรมเมอร์ไปบ้าง
โดยที่ขั้นตอนการพัฒนาแบบ Extreme programming จะเริ่มจากการซอย requirement ให้เป็นหน่วยย่อยๆ ที่สุดพร้อมประเมินเวลาที่จะต้องใช้ในการพัฒนาหน่วยนั้นๆ (ในช่วงแรกๆ อาจจะยังประเมินไม่ถูกต้องนักแต่หลังจากชินแล้วจะง่ายขึ้น) แล้วเขียนใส่แผ่นกระดาษแข็งตัดเป็นการ์ด (เรียกว่า user stories) ให้ user เลือกว่าชิ้นไหนมีความสำคัญมากกว่า (More priority) เพื่อทำการพัฒนาขึ้นมาก่อน
จับคู่โปรแกรมเมอร์เพื่อทำการพัฒนาหน่วยย่อยนั้นๆ ( Module, Function, Method) โดยเมื่อพัฒนาเสร็จแล้วให้ user ตรวจสอบเมื่อพึงพอใจแล้วให้ user เลือก user stories ชิ้นใหม่ขึ้นมา จับคู่โปรแกรมเมอร์ใหม่แล้วพัฒนาต่อไปจนจบ
หลักการเขียนโปรแกรมแบบ Extreme programming (Simplicity)
จะต้องเขียน Unit test ก่อนที่จะพัฒนาโปรแกรม!!! เพื่อเป็นการตรวจสอบ Module ของเราว่าทำงานได้อย่างถูกต้อง และเพื่อให้ง่ายในการตรวจสอบเมื่อมีการแก้ไขโค๊ดโดยบุคคลอื่นๆ (เพราะเราใช้โปรแกรมเมอร์สองคนในการพัฒนา 1 module ถ้าไม่มีการคุมกรอบไว้จะทำให้การแก้ไขโค๊ดเป็นไปอย่างยากลำบาก เนื่องจากกลัวว่าแก้แล้วจะทำงานผิดพลาด ถ้าเรามี unit test โปรแกรมเมอร์ที่มาแก้ไขจะสามารถตรวจสอบได้ด้วยตนเองจนพอใจ) หรือแม้กระทั่งตัวเราเองเมื่อเวลาผ่านไปนานมากๆ (จนตัวโปรแกรมเมอร์ที่พัฒนาเองอาจจะลืมไปแล้ว) เรียกกระบวนการนี้ว่า test-driven development
อ้างอิง
Java™ Extreme Programming Cookbook
By Eric M. Burke, Brian M. Coyner
น้องเอ
เขียนบันทึกบ่อย ๆ นะค่ะ สมาชิกใน Gotoknow.org จะได้เรียนรู้เรื่องนี้มากยิ่งขึ้นค่ะ
น้องเอค่ะ
พี่นำบันทึก การตั้งชื่อบล็อก มาให้ลองอ่านค่ะ อาจจะเป็นประโยชน์และแนวทางที่ดี ในการตั้งชื่อ blog เพื่อเป็นประโยชน์ต่อการใช้งานด้วย
ส่วนบันทึกการใช้งานอื่น ๆ ลองอ่านได้ที่ FAQs คำแนะนำแก้ไขปัญหาการใช้งาน Gotoknow
ฝากเนื้อฝากตัวด้วยนะครับ คุณ Patrickz
และเจ๊ มะปรางเปรี้ยว