การแก้ไขข้อขัดแย้งผสานเนื่องจากการเปลี่ยนโครงสร้างใหม่


13

ฉันได้มีส่วนร่วมในการอภิปรายเมื่อเร็ว ๆ นี้เกี่ยวกับวิธีจัดการ refactoring โดยทั่วไป (ซึ่งเป็นหัวข้อที่น่าสนใจในตัวเอง) ในที่สุดคำถามต่อไปนี้เกิดขึ้น:

หนึ่งจัดการข้อขัดแย้งผสานที่เกิดขึ้นเนื่องจากมีคนทำ refactoring ส่วนหนึ่งของรหัสในขณะที่คนอื่นกำลังทำงานในคุณสมบัติสำหรับรหัสชิ้นเดียวกันได้อย่างไร

โดยพื้นฐานแล้วฉันไม่มีความคิดวิธีจัดการกับสิ่งนี้อย่างมีประสิทธิภาพ มีวิธีปฏิบัติที่ดีที่สุดที่ควรปฏิบัติตามในเรื่องนี้หรือไม่? มีความแตกต่างในวิธีการจัดการนี้สำหรับระบบที่มีรหัสดั้งเดิมมากมายหรือไม่?


ฉันมีคำถามที่คล้ายกัน แต่มีข้อกำหนดแตกต่างกันดังนั้นฉันจึงเพิ่มคำถามอื่น programmers.stackexchange.com/questions/109229/…
Roger CS Wernersson

คำตอบ:


9

คำถามที่ดี. กลยุทธ์ที่ดีที่สุดที่ฉันนึกได้คือ

การป้องกัน

การรวมกันของการรวมอย่างต่อเนื่องและการทำให้การรีฟอร์เรชั่นขนาดเล็กบ่อยครั้ง (แทนการรีฟิลขนาดใหญ่เป็นครั้งคราว) จะช่วยลดค่าใช้จ่ายและความถี่ของความขัดแย้งดังกล่าวได้


3

ฉันคิดว่าจะตอบคำถามของคุณก่อนอื่นเราต้องดูว่าทำไมความขัดแย้งจึงเกิดขึ้นและอะไรคือความหมายที่แท้จริงและกระบวนการรวมกัน?

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

ในลักษณะนี้หมายความว่าผู้พัฒนารายที่สองมีบางสิ่งในใจที่แตกต่างจากผู้พัฒนารายแรก ความแตกต่างนี้อาจแตกต่างกันไปจากการใส่สไตล์เช่นการใช้งานnew UserManager().GetUserName()แทนการใช้UserManager userManager = new UserManager(); userManager.GetUserName();งานจนถึงระดับที่คุณกล่าวถึงซึ่งหมายความว่านักพัฒนาทั้งสองมีแนวคิดที่แตกต่างกันในการปรับเปลี่ยนรหัสเพื่อปรับปรุง

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

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

ฉันไม่เห็นด้วยกับการป้องกันสถานการณ์เหล่านี้เนื่องจากเราควรมีแนวโน้มที่จะเป็นจริงมากกว่าทางทฤษฎี บางครั้งผู้ชายก็เก่ง CSS จริงๆในขณะที่อีกคนเก่ง ASP.NET ASP.NET แต่งานของพวกเขาอาจขัดแย้งกันเมื่อพวกเขาควรทำงานบนหน้าเข้าสู่ระบบเพื่อให้มันทำงาน ฉันหมายถึงถ้าเราคิดว่าจริง (ไม่เหมาะ) เราจะเห็นว่าปรากฏการณ์นี้ (ความขัดแย้ง) เกิดขึ้นหลายครั้ง

อีกจุดที่ฉันอยากพูดถึงคือการใช้เครื่องมือเพื่อช่วยคุณในกระบวนการเช็คอินของคุณ เครื่องมือเหล่านี้มักจะเห็นภาพความแตกต่างของรหัสเซิร์ฟเวอร์และรหัสนักพัฒนาซอฟต์แวร์และช่วยในการกำหนดส่วนที่ควรเช็คอิน


3

หากไม่มีการจัดการงานที่ใช้งานอยู่คุณมีข้อขัดแย้ง

อย่างไรก็ตามหากคุณมีการประชุมประจำวันหรือผู้จัดการคุณอาจไม่สามารถมีปัญหานี้ได้

ทั้งพูดคุย (ผ่านลุกขึ้นยืนทุกวัน) หรือพูดคุยกับผู้จัดการ

นี่คือการป้องกันเล็กน้อยโดยการพูดคุย


+1 นักพัฒนาบางคนมองว่าผู้จัดการเป็นอุปสรรค แต่ผู้จัดการมีอยู่จริงเพื่อให้คนอื่นทำงานและนี่คือตัวอย่างที่ยอดเยี่ยมของปัญหาที่พวกเขาสามารถช่วยได้
MarkJ

@ MarkJ: ผู้จัดการที่เป็นอุปสรรคในการรวมความขัดแย้งไม่ใช่สิ่งเลวร้าย จุดที่ดีเยี่ยม
S.Lott

+1 ฉันเพิ่งจะเพิ่มบางอย่างเช่นนี้ในคำตอบของฉัน แต่คุณตอกมัน หากคุณกำลังใช้ความขัดแย้งเพื่อแจ้งให้คุณทราบว่ามีคนอื่นกำลังทำงานอยู่ในพื้นที่เดียวกันคุณจะต้องพบกับความล่าช้าในเกมแล้วต้องจัดการกับมัน การจัดการงานและการสื่อสารสามารถช่วยให้นักพัฒนาที่ทำงานในพื้นที่เดียวกันในการทำงานร่วมกันจากจุดเริ่มต้น
Gyan aka Gary Buyn

1

มีสาขาทั่วไปแยกต่างหากสำหรับการพัฒนาคุณลักษณะบางอย่างผสาน / ดึง / ดันบ่อยๆ - นั่นคือมัน

และสื่อสารกัน พูดคุยกับนักพัฒนาซอฟต์แวร์คนอื่น ๆ เกี่ยวกับรหัสแม้ขณะเปิดตัว แม้เมื่อการเข้ารหัส)))


1

ตรวจสอบให้แน่ใจว่าการผสานนั้นง่ายที่สุด การปรับโครงสร้างใหม่มักจะเป็นกระบวนการทางกลไกที่จะเปลี่ยนแปลงบรรทัดที่มีอยู่จำนวนมาก : ย้ายการประกาศตัวแปรเปลี่ยนแปลงช่องว่างการจัดรูปแบบลำดับของการดำเนินการ การสร้างฟีเจอร์มักจะเป็นการร่วมทุนที่สร้างสรรค์มากขึ้นซึ่งมักจะส่งผลให้เกิดโค้ดใหม่บวกกับการปรับแต่งเล็กน้อยของโค้ดที่มีอยู่ ตอนนี้หากนักพัฒนาที่ทำ refactoring บันทึกขั้นตอน (เช่นเป็นนิพจน์ทั่วไป) มันจะง่ายกว่ามากที่จะนำสิ่งเหล่านี้ไปใช้กับโค้ดด้วยฟังก์ชั่นพิเศษแทนที่จะใช้วิธีอื่น จากนี้ฉันจะบอกว่าตามกฎทั่วไปคุณควรใช้การเปลี่ยนแปลงที่ซับซ้อนที่สุดก่อนตามด้วยการเปลี่ยนแปลงที่ง่ายกว่า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.