เป็นวิธีที่ดีที่สุดในการจัดการ refactoring ไฟล์ขนาดใหญ่อะไร

ขณะนี้ฉันกำลังทำงานในโครงการที่ใหญ่กว่าซึ่งน่าเสียดายที่มีไฟล์บางไฟล์ที่มีแนวทางด้านคุณภาพซอฟต์แวร์ที่ไม่ได้ติดตามตลอด ซึ่งรวมถึงไฟล์ขนาดใหญ่ (อ่าน 2,000-4,000 บรรทัด) ซึ่งมีฟังก์ชั่นการใช้งานที่แตกต่างกันอย่างชัดเจน

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

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

ดังนั้นมีวิธีการ refactor ไม่ต้องการให้คนอื่นหยุดทำงาน (นาน) หรือผสานสาขาคุณลักษณะของพวกเขาเพื่อพัฒนา?

คุณเข้าใจอย่างถูกต้องว่านี่ไม่ใช่ปัญหาด้านเทคนิคเป็นปัญหาสังคม: หากคุณต้องการหลีกเลี่ยงความขัดแย้งที่มากเกินไปทีมต้องทำงานร่วมกันในลักษณะที่หลีกเลี่ยงความขัดแย้งเหล่านี้

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

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

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

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

1. แยกฟังก์ชันการทำงานเป็นโมดูลแยกต่างหาก
2. เปลี่ยนฟังก์ชั่นเก่าเพื่อส่งต่อการโทรไปยัง API ใหม่
3. เมื่อเวลาผ่านไปรหัสพอร์ตขึ้นกับ API ใหม่
4. ในที่สุดคุณสามารถลบฟังก์ชั่นเก่า
5. (ทำซ้ำสำหรับฟังก์ชันการทำงานกลุ่มถัดไป)

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

แต่ในที่สุดการแก้ปัญหาใด ๆ จะทำให้คุณต้องประสานงานกับทีมของคุณ

ทำ refactoring ในขั้นตอนที่เล็กลง สมมติว่าไฟล์ขนาดใหญ่ของคุณมีชื่อFoo:

1. เพิ่มไฟล์ว่างใหม่Barและส่งไปที่ "trunk"

2. ค้นหาส่วนเล็ก ๆ ของรหัสในซึ่งสามารถย้ายไปFoo Barใช้การย้ายอัปเดตจาก trunk สร้างและทดสอบโค้ดและคอมมิทกับ "trunk"

3. ทำซ้ำขั้นตอนที่ 2 จนกระทั่งFooและBarมีขนาดเท่ากัน (หรือขนาดใดก็ได้ที่คุณต้องการ)

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

สิ่งนี้จะไม่ขจัดข้อขัดแย้งที่ผสานหรือความจำเป็นในการแก้ไขด้วยตนเอง แต่จะ จำกัด แต่ละข้อขัดแย้งในพื้นที่ขนาดเล็กของรหัสซึ่งสามารถจัดการได้ง่ายกว่า

และแน่นอน - สื่อสารการปรับโครงสร้างในทีม แจ้งให้เพื่อนของคุณทราบว่าคุณกำลังทำอะไรดังนั้นพวกเขาจึงรู้ว่าทำไมพวกเขาจึงต้องคาดหวังว่าจะมีการรวมความขัดแย้งสำหรับไฟล์นั้น ๆ

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

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

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

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

ฉันจะแนะนำวิธีแก้ไขปัญหาที่แตกต่างจากปกติ

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

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

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

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

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

เพื่อช่วยขายแนวคิดนี้ให้กับผู้จัดการของคุณให้กล่าวถึงบิตการตรวจสอบโค้ดรวมถึงทุกคนที่รู้ว่าสิ่งใดมาจากจุดเริ่มต้น การป้องกันไม่ให้ devs เสียเวลาในการค้นหาโฮสต์ของไฟล์ใหม่นั้นคุ้มค่าที่จะหลีกเลี่ยง นอกจากนี้การป้องกันไม่ให้ devs รับ POed ว่าสิ่งใดสิ้นสุดลงหรือ "ขาดหายไปโดยสมบูรณ์" มักเป็นสิ่งที่ดี (ยิ่งการล่มสลายยิ่งน้อยเท่าไหร่ IMO ก็จะดีขึ้น)

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

อย่างไรก็ตามคุณตัดสินใจทำ refactor ของคุณโชคดี!

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

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

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

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

เบ็ดกระทำสามารถตรวจสอบชั้นเรียนใหม่หรือทำการวิเคราะห์แบบคงที่อื่น ๆ (เฉพาะกิจหรือไม่) นอกจากนี้คุณยังสามารถเลือกบรรทัดหรือจำนวนตัวอักษรที่ใหญ่กว่าไฟล์ 10% ในขณะนี้และบอกว่าไฟล์ขนาดใหญ่ไม่สามารถเติบโตเกินขีด จำกัด ใหม่ได้ นอกจากนี้คุณยังสามารถปฏิเสธการผูกมัดบุคคลที่ขยายไฟล์ขนาดใหญ่ด้วยจำนวนบรรทัดมากเกินไปหรืออักขระมากเกินไปหรือ w / e

เมื่อไฟล์ขนาดใหญ่หยุดการรวบรวมการทำงานใหม่คุณสามารถ refactor สิ่งต่าง ๆ ออกมาทีละครั้ง (และลด tresholds ที่บังคับใช้โดย hooks การกระทำในเวลาเดียวกันเพื่อป้องกันไม่ให้เติบโตอีกครั้ง)

ในที่สุดไฟล์ขนาดใหญ่จะมีขนาดเล็กพอที่จะทำการลบ hooks ได้อย่างสมบูรณ์

รอจนกว่าจะถึงเวลาทำการบ้าน แยกไฟล์กระทำและรวมเป็นหลัก

คนอื่นจะต้องดึงการเปลี่ยนแปลงในสาขาฟีเจอร์ของพวกเขาในตอนเช้าเหมือนกับการเปลี่ยนแปลงอื่น ๆ