ฉันจะจัดการ refactoring ที่ใช้เวลานานกว่าการวิ่งหนึ่งครั้งได้อย่างไร


49

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

อัปเดต: ผู้คนดูเหมือนจะต้องการคำอธิบายว่าทำไมสิ่งนี้ถึงไม่เหมาะกับการวิ่ง 2 สัปดาห์ มีส่วนร่วมในการวิ่งมากกว่าแค่การเขียนโค้ด เรามีนโยบายที่ไม่มีรหัสหากไม่มีการทดสอบ นโยบายนั้นไม่ได้มีอยู่เสมอและส่วนใหญ่ของ codebase ไม่มีอยู่ นอกจากนี้การทดสอบการรวมบางส่วนของเรายังเป็นการทดสอบด้วยตนเอง ปัญหาไม่ได้อยู่ที่การปรับโครงสร้างใหม่นั้นใหญ่มาก มันเป็นความจริงที่ว่าการเปลี่ยนแปลงเล็กน้อยมีผลกระทบกับหลาย ๆ ส่วนของระบบและเราต้องมั่นใจว่าชิ้นส่วนเหล่านั้นยังคงทำงานได้อย่างถูกต้อง

เราไม่สามารถชะลอหรือขยาย sprint ได้เนื่องจากเรามีโปรแกรมแก้ไขด่วนรายเดือน ดังนั้นการเปลี่ยนแปลงนี้ขยายผ่าน sprint ไม่สามารถหยุดงานอื่น ๆ ที่ถูกเพิ่มลงในโปรแกรมแก้ไขด่วน

Refactoring vs Redesign: เพียงเพราะกระบวนการพัฒนาของเราไม่ได้มีประสิทธิภาพเพียงพอที่จะจัดการ refactoring นี้ในรอบสองสัปดาห์ไม่รับประกันว่าจะเปลี่ยนชื่อเป็นการออกแบบใหม่ ฉันอยากจะเชื่อว่าในอนาคตเราสามารถทำงานเดียวกันให้สำเร็จภายในสองสัปดาห์เมื่อกระบวนการของเราดีขึ้น รหัสที่เป็นปัญหาที่นี่ไม่ต้องเปลี่ยนในเวลานานมากและค่อนข้างมีเสถียรภาพ ตอนนี้เมื่อทิศทางของ บริษัท ปรับเปลี่ยนได้มากขึ้นเราต้องการให้ส่วนฐานของโค้ดนี้สามารถปรับเปลี่ยนได้เหมือนกับส่วนที่เหลือ ซึ่งต้องมีการปรับสภาพใหม่ จากคำตอบที่นี่มันก็เห็นได้ชัดว่ามีความจำเป็นที่จะต้องทำให้นั่งร้าน refactoring ในกรอบเวลาของการวิ่งปกติ

ตอบ:

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


23
ขณะที่ทราบด้านนี้เป็นตามคำนิยามการออกแบบขนาดใหญ่ไม่ refactoring หวังว่าคุณจะไม่ใช้สิ่งนี้เป็น nitpicking - IMHO เป็นสิ่งสำคัญที่จะต้องใช้คำศัพท์ที่ชัดเจนเพื่อหลีกเลี่ยงปัญหาการสื่อสาร :-)
PéterTörök

9
@Charles "โดยปกติการสร้างใหม่จะทำในขั้นตอนเล็ก ๆหลังจากแต่ละขั้นตอนเล็ก ๆ คุณจะเหลือระบบการทำงานที่ไม่เปลี่ยนแปลงการใช้งาน " อ้างอิงจากหน้าเว็บที่ฉันลิงค์ด้านบน
PéterTörök

2
@Charles: การปรับโครงสร้างสามารถทำได้แบบเพิ่มหน่วยเสมอในขณะที่ทำให้ระบบทำงานได้ ใส่ความคิดเห็น "กำลังดำเนินการ Refactoring" ไว้ที่ด้านบนสุดของคลาส / แพ็คเกจ / โมดูลที่ได้รับการปรับโครงสร้างใหม่และทำชิ้นส่วนทีละรายการ หากคุณตัดการวางจำหน่ายชั่วคราวในขณะที่โมเดลวัตถุกำลังอยู่ในช่วงเปลี่ยนผ่าน
Sean McMillan

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

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

คำตอบ:


14

หากคุณมีความล่าช้าในการรีฟอร์เรชั่นฉันขอแนะนำให้เน้นการทำซ้ำในการเพิ่มการทดสอบหน่วยและการทดสอบการรวมเข้ากับจุดที่คุณสามารถ refactor ฐานรหัสได้อย่างง่ายดายจากนั้นทำการ refactor ในการวิ่งเพียงครั้งเดียว


68

คำแนะนำของฉัน:

  1. สร้างสาขา
  2. รวมทุกวันจากลำต้นไปยังสาขาของคุณและแก้ไขข้อขัดแย้ง
  3. ทำงานจนกว่าจะเสร็จ สาขาของคุณอาจอยู่นอกการพัฒนาหลักสำหรับการวิ่งหลายครั้ง
  4. ตัดกลับไปที่ลำต้น

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


1
เราได้พูดคุยกันโดยใช้วิธีการนี้และหากไม่มีแนวคิดอื่นออกมาก่อนที่เราจะแก้ไขปัญหานี่คือสิ่งที่เราวางแผนจะทำ
Charles Lambert

3
ฉันเกรงว่าคุณจะมีค่าใช้จ่ายจำนวนมากรวมตัวกันไปมาระหว่างท้ายรถกับกิ่งไม้ถ้าคุณต้องการที่จะทำการปรับโครงสร้างใหม่อย่างละเอียด
จอร์โจ

ในกรณีส่วนใหญ่ (หวังว่า) การเปลี่ยนแปลงที่ผสานจะไม่มีผลกับรหัสที่เป็นปัญหาที่นี่ ฉันจะไม่รังเกียจที่จะขยายกำหนดเวลาสำหรับการเปลี่ยนแปลงนี้หากมั่นใจว่าได้ผลลัพธ์ที่น่าเชื่อถือ
Charles Lambert

1
เมื่อพิจารณาถึงความผันผวนที่งานนำเสนอของคุณดูเหมือนจะแนะนำคุณอาจต้องพิจารณาGitเนื่องจากมันจะช่วยในการแยกและการรวมกลุ่มของการเก็งกำไรเช่นนี้
John Tobler

1
@Giorgio: ดังนั้นฉันการรวมรายวันดูเหมือนจะหวาดระแวงเล็กน้อย แต่จริงๆแล้วมันขึ้นอยู่กับขนาดของทีม ผู้คนมากขึ้นการเปลี่ยนแปลงมากขึ้นและบ่อยครั้งที่คุณควรรวม ดูเหมือนว่าทุกวันจะมีขีด จำกัด ด้านล่างหากคุณต้องการมีเวลาทำงาน
Matthieu M.

40

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


3
คำตอบของคุณคือข้อมูลที่ดีมากในหัวข้อ ฉันมาที่นี่เพื่อ "รับและทำ" ตามที่คุณพูด ฉันถามคำถามด้วยความหวังว่าจะได้รับข้อมูลบางอย่างเพื่อที่ฉันจะได้สามารถใช้กระบวนการที่ขนานกันกับกระบวนการที่มีอยู่ของฉันหรือแก้ไขกระบวนการปัจจุบันเพื่อแก้ไขสถานการณ์ปัจจุบันของฉัน ฉันต้องการสิ่งที่จะบอกนักพัฒนาเพื่อให้พวกเขามีแนวทางในการทำงานเช่นนี้จะเกิดขึ้นอย่างน้อย 2 ครั้ง
Charles Lambert

+1 สำหรับ "กระบวนการไม่สำคัญไปกว่าผลลัพธ์สุดท้ายและควรถูกมองว่าเป็นแนวทางมากกว่าเป็นกฎหมายที่ไม่เคยทำให้แตก" - ผู้คนดูเหมือนจะลืมสิ่งนี้จริงๆ
Bjarke Freund-Hansen

32

เพียงแค่วิ่ง 3, 4 หรือ 5 สัปดาห์ ใครสน? คุณเชื่อมั่นอย่างชัดเจนว่าไม่มีอะไรสามารถทำได้ในกรอบเวลาที่สั้นลงดังนั้นหยุดต่อสู้

อย่าบอกเพื่อนของคุณที่ The Royal Society of Blind Agile Adherance


ดูเหมือนว่าด้วยเหตุผลขององค์กร (การแก้ไขด่วนรายเดือน) การวิ่ง 2 สัปดาห์นั้นค่อนข้างยากที่จะเปลี่ยนแปลง
Steve Bennett

10

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


หนังสือที่ดีอย่างแน่นอน แต่ฉันไม่คิดว่ามันครอบคลุมการแบ่งการรีแฟคเตอร์ออกเป็นหลายครั้ง
อดัมเลียร์

4
ฉันจะให้ +1 นี้เพราะอาจเป็นหนังสือที่ดีที่สุดในการเริ่มต้นเมื่อคุณเริ่มเรียนรู้ตามที่ชื่อกล่าวว่าทำงานได้อย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม มันเกี่ยวข้องกับคนที่อาจถามคำถามนี้และไม่เข้าใจสิ่งที่เกี่ยวข้องกับการแบ่งสิ่งต่าง ๆ ออกเป็นขั้นตอนเล็ก ๆ
Charles Lambert

@Anna - จากนั้นคุณอาจต้องการ (อีกครั้ง) อ่านบทที่ 25 ซึ่งพูดถึงเทคนิคในการทำลายข้อต่อต่างๆที่ป้องกันการเปลี่ยนแปลงเล็กน้อย
kdgregory

@kdgregory ยุติธรรมเพียงพอ :) ใจเพิ่มที่คำตอบของคุณเพื่อให้น่ากลัวมากขึ้น?
อดัมเลียร์

7

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

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


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

5

อุทิศหนึ่ง sprint เพื่อค้นหาวิธีการทำให้โค้ดทำงานได้อย่างถูกต้อง mid-refactor สิ่งนี้สามารถอยู่ในรูปแบบของเมธอดและคลาสที่เลิกใช้แล้วอะแด็ปเตอร์และสิ่งที่คล้ายกัน การปรับโครงสร้างใหม่ของคุณอาจทำให้โค้ดสกปรกขึ้นในเวลาอันสั้นเพื่อทำความสะอาดในระยะยาว ไม่เป็นไร. ตอนนี้คุณกำลังบอกว่าไม่สามารถทำได้ ฉันไม่คิดว่าเหมาะสม - คิดเกี่ยวกับสิ่งที่กระบวนการของคุณจะเป็นอย่างไรถ้ามันสามารถทำได้คิดเกี่ยวกับขั้นตอนที่คุณสามารถใช้เพื่อทำให้มันดังนั้น จากนั้นดำน้ำใน


เราได้ทำสิ่งเหล่านี้ทั้งหมดแล้ว นั่นคือเหตุผลที่ฉันแสดงออกอย่างชัดเจนว่ามันไม่สามารถพังทลายได้
Charles Lambert

จริงๆ? คุณใช้เวลาในการวิ่งทั้งหมดเพียงแค่วางแผนวิธีการปรับโครงสร้างใหม่โดยไม่ทำให้ระบบของคุณเสียหายและไม่มีอะไรเกิดขึ้น? ฉันพบว่ามันยากที่จะเชื่อว่าการวางแผนเฉพาะนั้นเกิดขึ้นโดยไม่มีอะไรเลย บางทีคุณต้องนำที่ปรึกษา (และไม่ใช่ฉันไม่ใช่คนเดียวไม่ได้พยายามขอ)
Carl Manaster

1
ฉันไม่ได้พูดอะไรเลย ฉันกำลังบอกว่าเราผ่านกระบวนการที่คล้ายกับที่คุณอธิบายและออกมาอีกด้านหนึ่งด้วยรหัสบางอย่างที่ไม่สามารถ refactored ในการวิ่งครั้งเดียว
Charles Lambert

ฉันกล่าวว่า: "อุทิศหนึ่ง sprint เพื่อหาวิธีรักษารหัสให้ทำงานอย่างถูกต้องใน mid-refactor" คุณพูดว่า "เราทำมาทั้งหมดแล้ว" ตอนนี้คุณพูดอย่างอื่นหรือไม่? ฉันขอโทษถ้าสิ่งนี้ฟังดูขัดใจ แต่ฉันไม่เข้าใจ
Carl Manaster

5

+1 ในคำตอบของ Corbin March นั่นคือสิ่งที่ฉันคิด ดูเหมือนว่ารหัสฐานของคุณนั้นน่าเกลียดนิดหน่อยและมันต้องใช้เวลามากกว่าหนึ่งรอบการปั่นเพื่อทำความสะอาด
ดังนั้นเช่นเดียวกับคอร์บินกล่าวว่า

  1. แยกมันให้เป็น "โครงการฟื้นฟู"
  2. ทดสอบการเปลี่ยนสาขาของคุณ
  3. ส่งเสริมสภาพแวดล้อมการทดสอบของคุณสำหรับการทดสอบ QA
  4. ผสานมันกลับเข้าไปในลำต้นแบบค่อยเป็นค่อยไปจนกว่าการรีแฟคเตอร์จะเสร็จสิ้น

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


1
ฉันมีกระสุนทั้งหมดที่ฉันต้องพูดคุยกับทุกคน ฉันต้องการแผนอย่างเป็นทางการในการดำเนินการเมื่อฉันนำเสนอ จากคำตอบที่นี่ฉันไม่สงสัยเลยว่าฉันจะคิดวิธีแก้ปัญหาที่ทำซ้ำได้
Charles Lambert

4

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

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


3

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

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


การวิ่ง 4 สัปดาห์ควรครอบคลุม อย่างไรก็ตามเราไม่สามารถหยุด sprints 2 สัปดาห์ปัจจุบันเนื่องจากการแก้ไขบั๊กอื่น ๆ ฯลฯ ดังนั้นสิ่งนี้จะต้องขยายผ่านการวิ่งมากกว่าหนึ่งครั้ง ดังนั้นปมปัญหาของฉัน
Charles Lambert

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

ไม่ใช่สถานะที่สอดคล้องที่ตรวจสอบได้
Charles Lambert

ฉันต้องเพิ่ม wave ของฉันลงในความพยายามที่คนอื่นทำเพื่อหวังว่าคุณจะพบคำอื่นที่จะใช้แทน "refactoring" การปรับโครงสร้างใหม่นั้นได้รับการกำหนดไว้อย่างดีและขอบเขตของมันนั้นมากขึ้นในทันทีและในระยะสั้นกว่าการออกแบบและการเขียนโปรแกรมซ้ำขนาดใหญ่และใช้เวลานานที่คุณต้องทำ
John Tobler

2

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

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


เราไม่สามารถนำออกได้ตลอดไปและคำตอบของคุณไม่ได้ระบุวิธีดำเนินการปรับโครงสร้าง
Charles Lambert

@Charles: 'กำหนดเวลาไว้อีกครั้ง' ;) ฉันไม่ได้บอกว่ายกเลิกโครงการ
IAbstract

2

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

ให้ฉันสองโน้ตเล็ก ๆ เกี่ยวกับคำตอบอื่น ๆ ได้ที่นี่:

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

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

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

ทำ Refactoring Scratch และรักษามันเช่นนี้ (การจัดเรียงต้นแบบใหม่ "ทิ้งไป" บิต "ทิ้งไป" เป็นสิ่งสำคัญ!) จริงๆแล้วมันไม่น่าเป็นไปได้ที่คุณจะรู้ว่าผลกระทบทั้งหมดของการปรับโครงสร้างจะมี การซ่อมแซมรอยขีดข่วนจะช่วยคุณในเรื่องที่เกี่ยวกับ:

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

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

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

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



0

เรามีงานสองประเภทที่อยู่ในมือของเรา:

  1. ชั่วโมงทำงาน
  2. จีเนียสทำงาน

Refactoring มักจะประกอบด้วยชนิดแรกของการทำงานตั้งแต่มากในวิธีการที่เป็นที่รู้จักอยู่แล้วให้กับนักพัฒนาเช่นแห้ง , SRP , OCP , DI , ฯลฯ ดังนั้นเมื่อโครงการจะใช้เวลาสองเดือนที่จะ refactored, มันก็จะใช้เวลาสองเดือนมี ไม่มีทางรอบ ๆ มัน ดังนั้นข้อเสนอแนะของฉันจะไม่ refactor โครงการเดิมและปล่อยให้มันทำงานในสถานการณ์ปัจจุบัน หยุดได้รับการร้องขอใหม่และความต้องการจากผู้มีส่วนได้เสียและเจ้าของผลิตภัณฑ์ จากนั้นให้ทีมทำงานในโครงการจนกว่าจะได้รับการฟื้นฟูและพร้อมที่จะไป


0

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

อีกวิธีหนึ่งคือการทำสำเนารหัสที่ละเมิดให้ทำการ refactor แล้วย้ายลูกค้าทีละครั้งไปยังรหัสใหม่ งานนี้สามารถถูกแบ่งย่อยข้ามการวนซ้ำได้

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

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