วันนี้ได้ยินศัพท์ใหม่ชื่อว่า Commit Driven Development (CDD) จากพี่ Michael Athiwat Wongwaisayawan
ใน post บน facebook ซึ่งบอกว่ามันจะช่วยให้เรารู้ก่อนว่าจะลงมือทำอะไร ส่งผลให้ commit message สวยงามขึ้น
ดังนั้นมาดูกันดีกว่าว่า CDD มันคืออะไร และมีความเป็นมาอย่างไร
ตลอดจนเราจะใช้งานอย่างไร

[fb_embed_post href=”https://www.facebook.com/photo.php?fbid=10152184437342371″ width=”550″/]

เริ่มต้นด้วยการทำความรู้จัก

เรารู้จักกับคำว่า TDD (Test Driven Development) คือการที่เราต้องเขียน code ของ test
ก่อนที่ทำการการเขียน production code หรือบางคนอาจจะเรียกว่า Test First Driven Development

เรารู้จักกับคำว่า BDD (Behavior Driven Development) และ ATDD (Acceptance Test Driven Development)
คือการที่เราต้องเขียนอธิบายพฤติกรรมการใช้งานหรือทำงานของระบบหรือ feature ของงาน
ในรูปแบบที่สามารถ execute ได้ โดยที่ยังไม่มี code หรือระบบขึ้นมาเลย
โดยการเขียนนั่นอาจจะเรียกว่า scenario ของการทำงานใน feature นั้นๆ
บางคนอาจจะเรียกว่า SDD (Scenario Driven Development)

ดังนั้น CDD (Commit Driven Development) มันก็ไม่น่าจะแตกต่างจากทั้งสามแนวคิดมากนัก
นั่นก็คือ การเขียน commit message ของสิ่งที่เราจะทำต่อไปก่อนที่จะลงมือทำ
โดยข้อดีของแนวคิดนี้ก็คือ

  • จะทำให้คุณรู้ว่าสิ่งที่คุณจะทำต่อไปคืออะไร
  • เป็นการคิดในเรื่องการทำงาน และออกแบบ ครั้งละเล็กๆ ก่อนเริ่มทำงาน
  • ถ้าขณะที่ทำมีงานอะไรมาขัดจังหวะคุณ เมื่อคุณกลับมาทำงานสามารถอ่าน commit message ที่กำลังทำอยู่ได้
  • ทำให้การ review code หรือ review commit ได้อย่างรวดเร็ว และง่าย
  • การกลับไปดู history ของการ commit จะเข้าใจได้ง่าย … ลองกลับไปดู commit message ของงานที่คุณพัฒนาอยู่ว่าเป็นอย่างไร

สามารถสรุปกฎของ CDD ได้ง่ายๆ ดังนี้

กฎข้อที่ 1 ::  เขียน commit message ก่อนที่จะเขียน code
กฎข้อที่ 2 ::  commit message นั้นเขียนเพื่อบอกว่า product/software มันทำงานอะไร ไม่ใช่บอกว่าคุณทำอะไร

ข้อแนะนำเกี่ยวกับการเขียน commit message

  • ใช้สำหรับตอบคำถาม ระบบที่จะสร้างขึ้นมานั้นคืออะไร ทำงานอย่างไร ไม่ใช่เป็นการบอกว่าเรากำลังทำอะไร
  • ถ้า commit message มีการทำงานมากกว่า 1 อย่าง แนะนำให้แยก commit message ออกจากกัน
  • พยายาม commit บ่อยๆ และเล็กๆ
  • ให้คิดว่าแต่ละ commit message คือ release note ของ product ที่เรากำลังสร้างขึ้นมา
  • อย่าเขียน commit message ที่อ้างถึงสิ่งที่ผ่านไปแล้ว อธิบายสถานปัจจุบันจะดีที่สุด
  • แต่ละ commit message จะมีเวลาผูกด้วยอยู่แล้ว ดังนั้นไม่ต้องใส่ข้อความที่เกี่ยวกับเวลาลงไปนะ

คำแนะนำ

ถ้านำแนวคิด CDD มาทำงานร่วมกับ TDD หรืออะไรก็ตาม ก็จะแจ่มมากๆ
ไม่เชื่อลองทำดูสิครับ … แล้วจะทำให้คุณเห็นผลลัพธ์ในอีกแบบอย่างแน่นอน

แล้วนำมาใช้งานจริงๆ อย่างไรล่ะ

ผมลองนำแนวคิดมาใช้ร่วมกับ git
โดยสามารถเริ่มได้ง่ายๆ ดังนี้

1. กำหนด commit message ก่อนว่าจะทำอะไร ดังนี้

$message="File of xxx report files over 10mb are rejected"

2. ในการ commit สามารถใส่ message ไปง่ายๆ ดังนี้

$git commit -am "$message"

เพียงเท่านี้คุณก็สามารถเริ่มพัฒนาตามแนวคิด Commit Driven Development ได้แล้ว
และให้เป็นกิจกรรมที่เกิดขึ้นก่อนเข้าวงจรของ TDD นะครับ จะมีประโยชน์มาก
ดังนั้น ลองเริ่มทำดูครับ ไม่ลองไม่รู้

หรือกลับไปดู commit message ในสิ่งที่คุณและทีมทำมาครับ ว่ามันอ่านแล้วรู้เรื่องหรือไม่ ?
ถ้ายังไม่รู้เรื่องแสดงว่า ถึงเวลาที่คุณควรปรับปรุงแล้วครับ

Reference Websites
http://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/
http://www.kjetilk.com/2012/10/commit-driven-development.html

Tags: