การพัฒนาซอฟต์แวร์ร่วมกันระหว่างทีม developers นั้น เรื่องพื้นฐานที่น่าจะได้ทำกันทุกทีมคือการแบ่งงาน และรวมโค้ดกัน ซึ่งแน่นอนว่าปัญหาคลาสสิคมักเกิดขึ้นได้หากไม่รอบคอบมากพอหรือไม่ได้ผ่านการรีวิวโค้ดที่ดี ปัญหานั้นก็คือมีโค้ดไม่พึงประสงค์ติดขึ้นไปทำให้เกิดปัญหาตามมาบน Production Branch ด้วย 

โดยปัญหาเหล่านี้อาจเกิดขึ้นได้จากหลายสาเหตุ เช่น

 - การ Merge Code ที่ไม่สมบูรณ์

 - การไม่มี Test คลุม Logic code มากพอ

 - การแบ่งตัด Scope Release ที่ไม่ชัดเจนรวมไปถึงการ Release Feature ที่ยังใช้ได้ไม่ครบ flow

เรามาเริ่มจากเรื่องง่าย ๆ กันก่อนที่เรื่อง "การ Merge Code ที่ไม่สมบูรณ์"

แน่นอนว่าการทำงานกับ version control อย่าง branching แยกกันไปทำนั้นต้องเกิด conflict เป็นธรรมดา

Merged conflict คืออะไร?

Merged conflict คือการที่มีการแตก branch ออกไป develop แยกกัน โดยที่มีการแก้ไขไฟล์เดียวกันซึ่งโค้ดนั้นอาจมีการทับซ้อน หรืออยู่บรรทัดเดียวกัน เมื่อใครคนใดคนหนึ่งนำโค้ดมา Merge รวมกันนั้นจะเกิดสิ่งที่เรียกว่า Conflict คือโค้ดของทั้งสองคนมีความขัดแย้งกัน เข้ากันไม่ได้ ต้องทำอะไรบางอย่างเพื่อแก้ปัญหาก่อนที่จะทำการ Commit และนำไปใช้ต่อ

วิธีแก้ Conflict แต่ละรูปแบบที่จะนำหยิบยกมาเป็นตัวอย่างมีดังนี้

1 .หาเอง แก้เอง (อันนี้อย่าทำ!! มันเหนื่อย แค่ให้รู้เอาไว้เฉยๆ)

ก่อนอื่นเริ่มจากการเข้าใจ Conflict pattern ก่อน เราจะรู้ได้ยังไงว่าตรงไหนของ Code เราบ้างที่เป็น Conflict ? สังเกตุง่าย ๆ คือจะมี pattern ประมาณนี้เกิดขึ้นมาในโค้ดเรา

ตัวอย่าง pattern การแจ้ง conflict

จะเห็นว่าบล็อกที่เกิด Conflict จะเป็นวงเล็บเปิดปิด แล้วแยกโค้ดปัจจุบันกับโค้ดปลายทางที่จะ Merge เข้ามาด้วยการคั่นด้วยเครื่องหมาย  = 

โค้ดที่อยู่ในบล็อกด้านบน คือโค้ดใน branch ที่เราอยู่ปัจจุบัน ส่วนบล็อกด้านล่างจะเป็นโค้ดใน Branch ปลายทางที่เรานำมา merge ซึ่งหน้าที่ของเราคือต้องเลือกว่าจะทำอย่างไรกับโค้ดเหล่านั้น

โดยการเลือก Merge โค้ดนั้นมีแนวคิดดังนี้

1. เลือกโค้ดของเราทั้งหมด เหมาะกับกรณีที่เราเขียนโค้ดที่เป็นเวอร์ชันล่าสุดหรือโค้ดของเรานั้นเป็นโค้ดที่ถูกต้องล่าสุด

2. เลือกโค้ดของปลายทางทั้งหมด เหมาะกับกรณีที่ เราอาจจะไม่ได้ไปยุ่งอะไรด้วย หรือโค้ดเราเก่ากว่า และมีอัพเดทจากปลายทางเข้ามา

3. เลือกทั้งสองส่วนมาผสมกัน เหมาะกับการไปเจอโค้ดที่ซับซ้อนและต้องเลือกใช้โค้ดที่ถูกของแต่ละคนมารวมกัน

ตัวอย่างการ Merge branch a และ b

branch : a

branch : b

ไฟล์หลังจาก Merge branch a และ b

จะเห็นได้ว่ามี pattern conflict code ขึ้นมาบอกเราว่าเราต้องแก้โค้ดส่วนไหนบ้าง

ยังไงก็แล้วแต่หากเกิด Conflict ที่มีความซับซ้อนหรือไม่มั่นใจ คนที่จะนำโค้ดมา Merge “ต้อง” คุยกับเจ้าของโค้ดปลายทางที่เราจะหยิบมารวม เพื่อการตกลงและทำความเข้าใจร่วมกัน มิฉะนั้นอาจะเกิดปัญหาตามมาได้

------------------

"การเลือกโค้ดที่จะแก้ Conflict โปรดเลือกโค้ดที่จะเก็บไว้อย่างมีสติ

แต่สิ่งที่มีติดไว้จะอุ่นใจกว่าการมีสติ ก็คือควรมี Automation test เอาไว้จะอุ่นใจกว่า

แก้ปุ๊บ รันปั๊บ จะเขียว(pass) จะแดง(fail) ให้มันรู้กันไป !!"

------------------

2. ใช้เครื่องมือทุ่นแรง

มีเครื่องมือมากมายออกมาช่วยเราแก้ conflict code ซึ่งเราจะหยิบมาเล่าให้ฟังสักตัวที่ได้ใช้บ่อย ๆ

VS Code (https://code.visualstudio.com/) ใช่ครับ editor ที่เราใช้เขียนโปรแกรมนั่นแหละมีฟังก์ชันในการ detect conflict code ให้เราพร้อมกับตัวเลือกว่าเราจะ merge code นั้นด้วยวิธีไหน ถือว่าเป็นเครื่องมือที่ง่ายและสะดวกไม่ต้องลงอะไรเพิ่มให้ต้องกวนใจ

ตัวอย่างการใช้งาน VS Code ในการแก้ conflict

มี Hilight สวยงามพร้อมฟังก์ชันให้เลือกแก้ conflict ที่เข้าใจง่าย

ทีนี้เรามาลองแก้ Code ชุดนี้ให้กลับมาทำงานได้กันดู

แก้ Conflict แล้วออกมารันได้เหมือนเดิม พร้อม Commit กลับไปใน Branch หลักได้!!

สำหรับบล็อกหน้าเราจะมาคุยกันเรื่อง "ปัญหาการไม่มี Test คลุม Logic code มากพอ" กันต่อไปครับ