ปัญหาหลักที่มักเจอเกี่ยวกับการจัดการ source code
ด้วย VCS (Version Control System) เช่น Git คือ
เราจะเลือก branch strategy แบบไหนดี ?
ยกตัวอย่างเช่น
- TBD (Trunk-Based Development)
- Integration branch (Master และ Develop)
- Feature branch/ Git flow
- Pull Request
จากสิ่งที่พบเจอมานั้น มีสิ่งที่น่าสนใจคือ
TBD ไม่เหมาะกันงานของเรา Integration branch ดีเลยนะ แต่งานของเราขึ้นไม่พร้อมกัน Feature branch/ Git flow มันใช่เลย แต่ ไป ๆ มา ๆ จำนวน branch เยอะมาก แต่ ไป ๆ มา ๆ แต่ละ branch มีอายุที่ยามนานมาก ๆ กว่าจะ merge ไปยัง branch หลัก Pull request ก็มีปัญหาเยอะ ในการ review อีกทั้ง code แย่และไม่ถูกต้อง ประเด็นคือ ทำไมแต่ละแนวทางมีแต่ปัญหานะ ? ทั้งที่เราทำงานเป็นรอบสั้น ๆ นะ ทั้งที่เราทำงานแบบ feature-based นะแต่เมื่อเราลงไปดูในรายละเอียด
ของแต่ละ branch แต่ละ feature พบสิ่งที่สะเทือนใจมาก ๆ คือ จำนวน commit เยอะมาก ๆ บางทีมบอกว่า แต่ละ commit มันคือแต่ละ task เลยนะ จำนวน commit มันบอกให้เรารู้ว่า มี task ที่ต้องทำเยอะมากมาย เมื่องานเยอะเกินไป ปัญหาจึงตามมา นั่นคือ ทำการ merge code กับ branch หลักก็ยาก conflict เพียบ ทดสอบก็ยาก การ deploy แต่ละครั้งจึงเจ็บปวดรวดร้าวดังนั้นสิ่งที่ควรทำเป็นอันดับแรกเลย คือการกำหนดจำนวนและขนาดของงานที่ทำก่อนเลยยกตัวอย่างเช่น ทำทีละงาน กำหนดเวลาหรืออายุของ feature branch ที่สร้าวขึ้นมา เมื่อสิ้นสุดเวลาที่กำหนด หรือ งานที่ทำเสร็จแล้ว ให้ทำการ merge, test และ deploy กันเลย ที่สำคัญคือ ลบ branch เมื่อทุกอย่างมีสำเร็จ โดยวิธีการนี้ มันช่วยทำให้เราเห็นว่า สิ่งที่เราทำนั้นเป็นอย่างไร การทำงานของเราเป็นอย่างไร เพื่อปรับปรุงและแก้ไขต่อไป ที่สำคัญจะทำให้เราเห็นว่า feature หรือ story ที่พัฒนานั้น ควรมีขนาดเล็กเท่าไรดี และไม่มี branch ที่มีอายุนาน ๆ อีกต่อไป
สุดท้ายแล้วการ Pull Request ก็จะง่ายขึ้น
ถ้า feature นั้นมันเล็ก กำหนดจำนวนและขนาดของแต่ละ task ที่ทำ คือ การแก้ไขปัญหาที่ต้นเหตุ ไม่ใช่ไปแก้ไขที่ปลายเหตุ เช่น ถ้า code มัน conflict กันมีเครื่องมืออะไรช่วยไหม !! เป็นต้นคำถามคือ วันนี้คุณมีปัญหาเรื่องนี้อยู่หรือไม่ ? ถ้ามี คำถามคือ คุณแก้ไขที่ต้นเหตุหรือปลายเหตุกันแน่ ?