วิธีการแก้ไขข้อผิดพลาดจากการรวม Source code ของทีม

เมื่อเช้านี้เห็นมีการ share บทความเรื่อง 4 Simple Tricks to Avoid Merge Conflicts ทำการอธิบายถึงการแก้ไขปัญหาต่าง ๆ ที่เกิดจากการรวม source code ของทีม ซึ่ง developer มักจะเรียกว่า Merge conflict จึงนำมาแปลกันนิดหน่อย น่าจะมีประโยชน์บ้างนะ มาดูกันว่ามีวิธีการอะไรบ้าง ?

คำถามที่มักได้รับเสมอจากการแบ่งปันเรื่อง Version Control System

ไม่ว่าจะเป็น Git, Mercurial HG และ SVN นั่นก็คือ ถ้า source code รวมกันแล้วเกิด Conflict หรือ ข้อขัดแย้ง จะต้องแก้ไขอย่างไรดี ?

ก่อนที่จะหาวิธีการแก้ไขปัญหา เราต้องรู้และเข้าใจก่อนว่า ที่ไปที่มาของปัญหามันคืออะไรกันแน่

ในการพัฒนา software ส่วนใหญ่ต้องทำงานเป็นทีม นั่นคือต้องมีคนทำงานร่วมกันมากกว่า 1 คน ต้องทำงานบน source code ชุดเดียวกัน ดังนั้นมีบ่อยครั้งที่ทำการแก้ไข source code เดียวกัน พร้อม ๆ กัน ส่งผลให้เกิดปัญหา คือ Merge conflict ซึ่งมันรบกวนจิตใจของนักพัฒนาอย่างมาก !! เนื่องจากต้องทำการแก้ไข conflict หรือ ข้อขัดแย้งเหล่านั้นเอง บางครั้งก็แก้ไขผิด ๆ ถูก ๆ บางครั้งทำให้ bug ที่แก้ไขไปแล้ว กลับมาอีก บางครั้งทำให้ feature ที่เคยทำงานได้ ทำงานไม่ได้ นั่นคือ ความบอบช้ำ และ เจ็บช้ำที่นักพัฒนาได้รับ แต่ก็ยังทำแบบนั้นซ้ำแล้วซ้ำอีก !! จึงเกิดคำถามขึ้นมาว่า จะแก้ไขปัญหาเหล่านี้อย่างไรดี บางคนอาจจะพยายามหาเครื่องมือที่ช่วยรวม หรือ merge source code แบบ GUI เพราะว่า มันง่ายดี แต่ผมคิดว่า เราน่าจะทำการแก้ไขปัญหาที่ต้นเหตุดีกว่า เพื่อหลีกเลี่ยงปัญหาที่จะเกิดขึ้น นั่นคือ ป้องกันไว้ดีกว่าแก้นะครับ (Prevent) ซึ่งจากบทความข้างต้นได้แนะนำไว้ 4 วิธีตามลำดับดังนี้

1. ทำการ Merge บ่อย ๆ สิ

ปัญหาใหญ่ ๆ ของ Merge conflict เกิดจากจำนวน source code ที่ชนหรือขัดแย้งกันมากเหลือเกิน คำถาม คุณทำการ merge source code กันบ่อยเพียงใด ? 2-3 วัน ? หนึ่งสัปดาห์ ? สองสัปดาห์ ? ครึ่งเดือน ? หนึ่งเดือน ?

สิ่งที่หนึ่งที่บอกได้เลยก็คือ ยิ่งใช้เวลานานเพียงใด ความเสี่ยงก็ยิ่งมากขึ้นเท่านั้น ยิ่งก็ให้เกิดข้อขัดแย้งขนาดใหญ่ และ มากมาย

ดังนั้น ถ้าคุณต้องการหลีกเลี่ยงปัญหาเหล่านี้ ให้ทำการ merge บ่อย ๆ ไปเลย นั่นคือ ทุกครั้งเมื่อคุณทำการเปลี่ยนแปลง หรือ commit source code นั่นเอง จะช่วยลดข้อขัดแย้งต่าง ๆ ลงไปอย่างมาก ถึงจะเกิดข้อขัดแย้ง ก็เป็นเพียงปัญหาเล็ก ๆ ซึ่งสามารถแก้ไขได้อย่างง่ายดาย

หัวใจคือ Fast feedback ครับ

2. เล็ก ๆ สิดี

ว่าด้วยเรื่องของ Single Responsibility Principle (SRP) เป็นหนึ่งในแนวทางการออกแบบระบบงานที่ดี คือ SOLID นั่นคือ ในหนึ่ง class ใน หนึ่ง method นั้น ควรจะมีหน้าที่การทำงานเพียงอย่างเดียวเท่านั้น หรือในแต่ละ class แต่ละ method ควรมีเหตุผลเดียวในการเปลี่ยนแปลงเท่านั้น ผลที่ได้ก็คือ นักพัฒนาจะไม่ทำงาน หรือ เปลี่ยนแปลง source code ที่เดียวกันอย่างแน่นอน ยกเว้นจะทำงานเดียวกัน หรือ ทำงานด้วยกัน ดังนั้น การออกแบบที่ดีมันช่วยให้ทีมทำงานร่วมกันได้อย่างดี ยิ่งแต่ละส่วนการทำงานเล็ก ๆ แล้ว ก็ยิ่งทำให้คุณภาพของการออกแบบระบบดี รวมทั้ง ลดความเสี่ยงจาก Merge conflict อีกด้วย

ลองกลับไปดู source code ของคุณดูสิว่า มีการแก้ไข source code อย่างไรกันบ้าง เช่น มี class ไหนที่ต้องแก้ไขบ่อยมาก ๆ จากทุก ๆ คน ทุก ๆ feature ?

3. การพูดคุย การสื่อสาร มันสำคัญอย่างมาก

Communication is a Key !!

แต่ละคนในทีมพูดคุยกันหรือไม่ ? แต่ละคนในทีมรู้หรือไม่ว่า เพื่อน ๆ แต่ละคนทำงานอะไร ? รู้หรือไม่ว่า แต่ละคนแก้ไข class อะไรกันอยู่ ? รู้หรือไม่ว่า สิ่งที่แก้ไขไปนั้นกระทบใครบ้าง ? ดังนั้น ถ้าคุณไม่รู้ ก็ควรพูดคุยกันซะเพื่อให้รู้ หรือบางครั้งต้องแก้ไข class เดียวกันอยู่ตลอดเวลา ทำไมไม่มานั่งทำงานด้วยกันไปเลยล่ะ !!

แก้ไขการ Merge conflict ได้ง่าย ๆ มากเลยนะ เพียงแค่เราคุยกันในเรื่องที่ควรจะคุยกันมากขึ้น

4. Mob programming

เป็นวิธีการที่ทรงประสิทธิภาพอย่างมาก และเชื่อได้เลยว่า แก้ไขปัญหา Merge conflict ได้ 100% เนื่องจากทุกคนมานั่งทำงานด้วยกัน ใช้เครื่องทำงานเดียวกัน ดังนั้น ไม่มีทางที่ source code จะขัดแย้งกัน แต่มันมีค่าใช้จ่ายที่สูงมาก ๆ ดังนั้นจึงเป็นวิธีการสุดท้ายที่จะทำนั่นเอง

วันนี้คุณทำการ merge source code กันบ่อย ๆ หรือไม่ ? ถ้าไม่ ก็เริ่มได้แล้ววันนี้ !!