xtreme programming ในบริษัท


แนวคิดในการพัฒนาโปรแกรมที่น่าสนใจ (จริงๆ ก็มีมานานแล้วละนะแต่ยังไม่ค่อยบูมในบ้านเราซักเท่าไหร่นัก)

Extreme Programming

อีกหนึ่งในทางเลือกของการการพัฒนา 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

หมายเลขบันทึก: 83605เขียนเมื่อ 13 มีนาคม 2007 02:45 น. ()แก้ไขเมื่อ 2 มิถุนายน 2012 00:55 น. ()สัญญาอนุญาต: จำนวนที่อ่านจำนวนที่อ่าน:


ความเห็น (5)

น้องเอ

เขียนบันทึกบ่อย ๆ นะค่ะ  สมาชิกใน Gotoknow.org จะได้เรียนรู้เรื่องนี้มากยิ่งขึ้นค่ะ

น้องเอค่ะ

พี่นำบันทึก การตั้งชื่อบล็อก มาให้ลองอ่านค่ะ อาจจะเป็นประโยชน์และแนวทางที่ดี ในการตั้งชื่อ blog เพื่อเป็นประโยชน์ต่อการใช้งานด้วย

ส่วนบันทึกการใช้งานอื่น ๆ ลองอ่านได้ที่ FAQs คำแนะนำแก้ไขปัญหาการใช้งาน Gotoknow

ยินดีต้อนรับครับ

ฝากเนื้อฝากตัวด้วยนะครับ คุณ Patrickz

และเจ๊ มะปรางเปรี้ยว 

อืม อย่างงี้ค่อยยังชั่วหน่อยครับ :-)
พบปัญหาการใช้งานกรุณาแจ้ง LINE ID @gotoknow
ClassStart
ระบบจัดการการเรียนการสอนผ่านอินเทอร์เน็ต
ทั้งเว็บทั้งแอปใช้งานฟรี
ClassStart Books
โครงการหนังสือจากคลาสสตาร์ท