คุณควร refactor รหัสที่มีอยู่ที่ไม่ได้ขาดในโครงการที่มุ่งเน้นคุณสมบัติใหม่?

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

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

อย่างแน่นอน

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

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

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

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

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

0- มีการร้องเรียนของลูกค้าเกี่ยวกับรหัสนี้หรือไม่

1- สิ่งนี้จำเป็นสำหรับการใช้งานของแอปพลิเคชันหรือไม่

2- รหัสปัจจุบันเป็นอันตรายหรือไม่?

3 - ราคาของการเปลี่ยนแปลงคุ้มค่าหรือไม่

4- คุณสามารถจ่ายได้หรือไม่

5 - นี่คือการใช้ทักษะที่ดีที่สุดของคุณไปยังองค์กร

6- การเปลี่ยนแปลงของคุณต้องการให้ผู้ใช้ของคุณติดตั้งการเปลี่ยนแปลงใหม่ - คุณสามารถปรับให้เหมาะสมกับลูกค้าได้หรือไม่

7- คุณสามารถทนต่อความเสี่ยงของการแก้ไขที่ไม่ดีได้หรือไม่?

8- การเปลี่ยนแปลงมีผลกับรหัสอื่นนอกโครงการของคุณหรือไม่

9- นี่คือผลิตภัณฑ์ที่พัฒนาหรือผลิตภัณฑ์ที่เสถียรหรือไม่? หากมีการพัฒนาคุณสามารถรวมการเปลี่ยนแปลงในรีลีสถัดไปได้หรือไม่?

Refactor เร็ว ๆ นี้ refactor บ่อยครั้ง

หากคุณสามารถจ่ายได้ (เวลาเงิน ฯลฯ ) คุณควรทำ

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

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

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

หากจำเป็นต้องทำการปรับโครงสร้างใหม่เพื่อใช้งานฟังก์ชันใหม่ก็ควรจะทำและแยกส่วนในการพัฒนาใหม่

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

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

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

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