Refactor ขนาดใหญ่: ทำไมคุณถึงเคยทำอะไรแบบนั้น?

ถ้ายังไม่พังอย่าซ่อม

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

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

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

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

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

บางทีคุณอาจมองพวกเขาอย่างจริงจังและบอกให้พวกเขาปล่อยวางและอย่าแตะต้องมัน

คำถาม“ ทำไมเราถึงอยากทำด้วย” เป็นเรื่องธรรมชาติและอาจสำคัญพอ ๆ กับการทำ ...

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

การปรับปรุงประสิทธิภาพ

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

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

การปรับปรุงสถาปัตยกรรม

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

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

นำมาให้ทันสมัย

บางครั้งโค้ดก็เขียนได้ดีในตอนแรก คุณมีความสุขมากกับมัน รวดเร็วหน่วยความจำมีประสิทธิภาพบำรุงรักษาได้และสอดคล้องกับข้อกำหนด ในเบื้องต้น. แต่แล้วข้อกำหนดก็เปลี่ยนไปเป้าหมายทางธุรกิจก็เปลี่ยนไปหรือคุณได้เรียนรู้สิ่งใหม่ ๆ เกี่ยวกับผู้ใช้ปลายทางที่ทำให้สมมติฐานเริ่มต้นของคุณไม่ถูกต้อง รหัสยังคงใช้งานได้ดีและคุณก็ยังคงพอใจกับมัน แต่มีบางอย่างที่น่าอึดอัดใจเมื่อคุณดูในบริบทของผลิตภัณฑ์สุดท้าย สิ่งต่าง ๆ ถูกวางไว้ในระบบย่อยที่ไม่ถูกต้องเล็กน้อยหรือคุณสมบัตินั่งอยู่ในคลาสที่ไม่ถูกต้องหรือบางชื่ออาจไม่สมเหตุสมผลอีกต่อไป ตอนนี้พวกเขากำลังทำหน้าที่ในแง่ธุรกิจที่มีชื่อแตกต่างกันอย่างสิ้นเชิง อย่างไรก็ตามยังคงเป็นเรื่องยากมากที่จะพิสูจน์ให้เห็นถึงการปรับโครงสร้าง Rails ขนาดใหญ่ทุกประเภทเนื่องจากงานที่เกี่ยวข้องจะเป็นไปตามขนาดกับตัวอย่างอื่น ๆ แต่ประโยชน์ที่จับต้องได้น้อยกว่ามาก เมื่อคุณคิดเกี่ยวกับเรื่องนี้การดูแลรักษามันไม่ยากเลย คุณต้องจำไว้ว่าจริงๆแล้วบางอย่างเป็นอย่างอื่น คุณต้องจำไว้ว่าจริงๆแล้ว A หมายถึง B และคุณสมบัติ Y บน A เกี่ยวข้องกับ C จริงๆ

ภาษาโปรแกรมที่ดีที่สุดสำหรับหุ่นยนต์

และนี่คือประโยชน์ที่แท้จริง ในสาขาจิตวิทยาประสาทมีการทดลองมากมายที่ชี้ให้เห็นว่าหน่วยความจำระยะสั้นหรือใช้งานได้ของเราสามารถเก็บองค์ประกอบได้เพียง 7 +/- 2 องค์ประกอบหนึ่งในนั้นคือ การทดลองของ Sternberg . เมื่อเราศึกษาเรื่องหนึ่งเราจะเริ่มต้นด้วยองค์ประกอบพื้นฐานและในขั้นต้นเมื่อเราคิดถึงแนวคิดระดับสูงขึ้นเราต้องคิดถึงคำจำกัดความของพวกเขา ตัวอย่างเช่นลองใช้คำง่ายๆว่า“ รหัสผ่าน SHA256 แบบเค็ม” ในขั้นต้นเราต้องยึดถือคำจำกัดความของหน่วยความจำการทำงานของเราสำหรับ 'เค็ม' และ 'SHA256' และอาจเป็นคำจำกัดความของ 'ฟังก์ชันแฮช' แต่เมื่อเราเข้าใจคำศัพท์อย่างถ่องแท้แล้วมันจะใช้ช่องหน่วยความจำเพียงช่องเดียวเพราะเราเข้าใจโดยสัญชาตญาณ นั่นเป็นสาเหตุหนึ่งที่เราต้องเข้าใจแนวคิดระดับล่างอย่างถ่องแท้เพื่อให้สามารถหาเหตุผลเกี่ยวกับแนวคิดระดับสูงกว่าได้ เช่นเดียวกับข้อกำหนดและคำจำกัดความเฉพาะสำหรับโครงการของเรา แต่ถ้าเราต้องจำคำแปลให้ตรงกับความหมายที่แท้จริงทุกครั้งที่เราพูดถึงโค้ดของเราการแปลนั้นกำลังครอบครองสล็อตหน่วยความจำที่ใช้งานได้ล้ำค่าอีกช่องหนึ่ง มันสร้างภาระทางความคิดและทำให้ยากต่อการหาเหตุผลผ่านตรรกะในรหัสของเรา ในทางกลับกันหากเหตุผลยากขึ้นก็หมายความว่ามีโอกาสมากขึ้นที่เราจะมองข้ามจุดสำคัญและแนะนำจุดบกพร่อง

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

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

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

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

การเตรียมการ

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

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

คุณจะต้องมีตัวช่วยสำหรับกระบวนการปรับโครงสร้างใหม่ คุณอาจชอบอย่างอื่น แต่ฉันชอบกระดาษเปล่าและปากกาธรรมดา ๆ ฉันเริ่มต้นด้วยการเขียนการเปลี่ยนแปลงเริ่มต้นที่ฉันต้องการทำที่ด้านซ้ายบนของกระดาษ จากนั้นฉันก็เริ่มมองหาสถานที่ทั้งหมดที่ได้รับผลกระทบจากการเปลี่ยนแปลงและเขียนไว้ใต้การเปลี่ยนแปลงครั้งแรก สิ่งสำคัญคือต้องใช้วิจารณญาณ ในที่สุดโน้ตและไดอะแกรมบนกระดาษจะอยู่ที่นั่นสำหรับตัวคุณเองดังนั้นจงเลือกรูปแบบที่เหมาะกับความทรงจำของคุณมากที่สุด ฉันเขียนข้อมูลโค้ดสั้น ๆ ที่มีสัญลักษณ์หัวข้อย่อยด้านล่างและลูกศรจำนวนมากที่นำไปสู่บันทึกอื่น ๆ ที่ระบุสิ่งที่ขึ้นอยู่กับมันโดยตรง (ลูกศรเต็ม) หรือโดยอ้อม (ลูกศรประ) ฉันยังใส่คำอธิบายประกอบลูกศรด้วยเครื่องหมายชวเลขเพื่อเตือนความจำบางสิ่งที่ฉันสังเกตเห็นใน codebase โปรดจำไว้ว่าคุณจะกลับมาที่บันทึกเหล่านั้นในอีกไม่กี่วันข้างหน้าในขณะที่คุณดำเนินการเปลี่ยนแปลงตามแผนและเป็นเรื่องปกติที่จะใช้การแจ้งเตือนที่สั้นและคลุมเครือเพื่อให้ใช้พื้นที่น้อยลงและจัดวางบนกระดาษได้ง่ายขึ้น . สองสามครั้งที่ฉันทำความสะอาดโต๊ะทำงานของฉันเป็นเวลาหลายเดือนหลังจากการปรับโครงสร้างทางรถไฟและฉันพบหนึ่งในเอกสารเหล่านั้น มันเป็นคำพูดพล่อยๆโดยสิ้นเชิงฉันไม่รู้เลยว่าสิ่งใดในกระดาษนั้นหมายถึงอะไรยกเว้นว่าอาจมีคนบ้าเขียนออกมา แต่ฉันรู้ว่ากระดาษแผ่นนั้นขาดไม่ได้ในขณะที่ฉันกำลังแก้ไขปัญหา นอกจากนี้อย่าคิดว่าคุณจำเป็นต้องเขียนการเปลี่ยนแปลงทุกรายการ คุณสามารถจัดกลุ่มและติดตามรายละเอียดด้วยวิธีอื่น ตัวอย่างเช่นในเอกสารหลักของคุณคุณสามารถสังเกตได้ว่าคุณต้อง“ เปลี่ยนชื่อที่เกิดขึ้นทั้งหมดของ A.b เป็น C.d” จากนั้นคุณสามารถติดตามข้อมูลเฉพาะได้หลายวิธี คุณสามารถเขียนทั้งหมดลงในกระดาษแยกต่างหากคุณสามารถวางแผนที่จะทำการค้นหาทั่วโลกสำหรับเหตุการณ์ที่เกิดขึ้นทั้งหมดอีกครั้งหรือคุณสามารถทิ้งไฟล์ต้นฉบับทั้งหมดไว้ในกรณีที่ต้องทำการเปลี่ยนแปลงในตัวแก้ไขที่คุณเลือก และจดบันทึกเพื่อย้อนกลับไปเมื่อคุณทำแผนที่การเปลี่ยนแปลงเสร็จสิ้น

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

การดำเนินการ

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

เมื่อคุณปรับโครงสร้างโค้ดจริงๆแล้วให้ใส่ใจกับโค้ดแปลก ๆ ที่ทำบางอย่างเฉพาะเจาะจงมากและอาจดูเหมือนโค้ดไม่ดี อาจจะเป็นรหัสที่ไม่ถูกต้อง แต่บ่อยครั้งที่พวกเขาจัดการกรณีมุมแปลก ๆ ที่ค้นพบขณะตรวจสอบข้อบกพร่องในการผลิต เมื่อเวลาผ่านไปรหัส Rails ส่วนใหญ่จะเพิ่ม 'เส้นขน' หรือ 'หูด' ซึ่งจัดการข้อบกพร่องของกรณีมุมแปลก ๆ เช่นรหัสตอบกลับแปลก ๆ ที่นี่อาจจำเป็นสำหรับ IE6 หรือเงื่อนไขที่จัดการกับข้อผิดพลาดเกี่ยวกับเวลาแปลก ๆ ไม่สำคัญสำหรับภาพใหญ่ แต่ยังคงเป็นรายละเอียดที่สำคัญ ตามหลักการแล้วพวกเขาได้รับการคุ้มครองอย่างชัดเจนด้วยการทดสอบหน่วยหากไม่พยายามครอบคลุมก่อน ครั้งหนึ่งฉันเคยได้รับมอบหมายให้ย้ายแอปพลิเคชันขนาดกลางจาก Rails 2 ไปยัง Rails 3 ฉันคุ้นเคยกับโค้ดเป็นอย่างดี แต่มันค่อนข้างยุ่งและมีการเปลี่ยนแปลงมากมายที่ต้องพิจารณาดังนั้นฉันจึงเลือกที่จะนำกลับมาใช้ใหม่ อันที่จริงมันไม่ใช่การนำกลับมาใช้งานจริงเนื่องจากแทบจะไม่เคยเป็นการเคลื่อนไหวที่ชาญฉลาด แต่ฉันเริ่มต้นด้วยแอป Rails 3 ที่ว่างเปล่าและฉันปรับโครงสร้างส่วนแนวตั้งของแอปเก่าให้เป็นแอปใหม่โดยประมาณโดยใช้กระบวนการที่อธิบายไว้ ทุกครั้งที่ฉันทำชิ้นส่วนแนวตั้งเสร็จฉันจะอ่านรหัส Rails เก่าดูที่แต่ละบรรทัดและตรวจสอบอีกครั้งว่ามีคู่กันในรหัสใหม่หรือไม่ โดยพื้นฐานแล้วฉันเลือก 'ขน' โค้ดเก่าทั้งหมดและจำลองในโค้ดเบสใหม่ ในท้ายที่สุด codebase ใหม่ก็มีการแก้ไขปัญหาทั้งหมด

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

ห่อมัน

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

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

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

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

เมื่อไหร่ที่คุณจะไม่ทำ?

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

ความครอบคลุมการทดสอบของคุณไม่ดี

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

การปรับโครงสร้างใหม่ไม่ได้ขับเคลื่อนด้วยคุณลักษณะใหม่และ codebase ไม่ได้เปลี่ยนแปลงมาเป็นเวลานาน

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

คุณถูกกดเวลา

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

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

สรุป

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