เมื่อ refactor

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

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

ฉันรู้สึกว่าควรจะมีวิธีการที่เข้มงวดมากขึ้นในเรื่องนี้ แต่ฉันไม่แน่ใจว่าพวกเขาเป็นอย่างไร

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

Refactor เมื่อค่าใช้จ่ายในการปรับสภาพน้อยกว่าค่าใช้จ่ายในการไม่ทำการปรับสภาพ

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

1. เป็นความซับซ้อน cyclomaticของการทำงานต่ำกว่า 5 หรือไม่
2. คุณเข้าใจความซับซ้อนของวัฏจักรอย่างสมบูรณ์โดยไม่ต้องติดตามลิงค์นั้นหรือไม่?
3. คุณมีการทดสอบอัตโนมัติหรือกรณีทดสอบที่ทำเป็นเอกสารสำหรับทุกเส้นทางผ่านฟังก์ชั่นหรือไม่?
4. กรณีทดสอบที่มีอยู่ทั้งหมดผ่านหรือไม่
5. คุณสามารถอธิบายฟังก์ชั่นการใช้งานและขอบเคสให้ฉันได้ในเวลาน้อยกว่า 1 นาทีหรือไม่?
6. ถ้าไม่ใช้เวลาประมาณ 5 นาที
7. 10 นาที?
8. มีฟังก์ชั่นของรหัสน้อยกว่า 100 บรรทัด (รวมถึงความคิดเห็น) หรือไม่?
9. คุณพบนักพัฒนาสองคนที่เห็นด้วยกับรหัสนี้ว่าปราศจากข้อผิดพลาดเพียงแค่ตรวจสอบด้วยภาพหรือไม่?
10. ฟังก์ชั่นนี้ใช้ในที่เดียวหรือไม่?
11. ฟังก์ชั่นตรงตามเป้าหมายประสิทธิภาพ (Time / Memory / CPU) หรือไม่?

เกณฑ์การให้คะแนน

เพิ่มคำตอบ "ไม่" ด้านบน:

• 0-1 - ทำไมคุณถึงคิดเกี่ยวกับการปรับโครงสร้างใหม่นี้ คุณอาจต้องการเปลี่ยนชื่อตัวแปรเนื่องจากคุณไม่ชอบรูปแบบการตั้งชื่อของนักพัฒนาคนก่อน
• 2-5 - นี่อาจต้องใช้การปรับแต่งเล็กน้อย แต่ฉันจะไม่ยอมหยุดการผลิตสำหรับบางอย่างในช่วงนี้
• 6-8 - ตกลงเราอาจต้องแก้ไขปัญหานี้ ... เป็นไปได้ว่าเราจะกลับมาทบทวนอีกครั้งและ / หรือเราไม่รู้ว่ามันกำลังทำอะไรอยู่ ยังอยู่ในรั้ว แต่ก็สงสัยอย่างมาก
• 9+ - นี่คือตัวเลือกอันดับต้นสำหรับการปรับโครงสร้างใหม่ (หมายเหตุการเขียนกรณีทดสอบเป็นรูปแบบหนึ่งของการปรับโครงสร้างใหม่)

เมื่อลำไส้ของคุณกำลังบอกคุณว่าคุณควรจะทำการปรับโครงสร้างบางอย่างมันอาจเป็นไปได้ว่าสัญชาตญาณของคุณจะบอกคุณช้าไปเล็กน้อยว่า

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

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

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

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

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

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

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

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

ฉันรู้สึกว่าการสอนเมื่อจะ refactor จริง ๆ ขึ้นอยู่กับ บริษัท ที่คุณอยู่ในปัจจุบัน

"เมื่อใดที่จะรีแฟคเตอร์?"

คำตอบสั้น ๆ : ทุกครั้งที่คุณเจอโค้ดที่มีกลิ่นไม่ดีหรืออาจปรับปรุงได้ ( กฎลูกเสือ )

จวนนี้เกิดขึ้น:

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

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

การใช้ Eclipse หรือ IDE ที่คล้ายกันซึ่งมีการสนับสนุนการปรับโครงสร้างที่แข็งแกร่งช่วยลดความพยายามในการทำการปรับโครงสร้างใหม่ การสนับสนุน IDE ทำให้มีโอกาสมากขึ้นที่คุณจะ refactor ทันทีที่คุณกดปุ่ม "ครั้งที่สาม" (หรือดูความต้องการ) แทนที่จะมองว่ามันเป็นความพยายามเพิ่มเติม

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

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

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

ในการเขียนโปรแกรม 20 ปีของฉันนี่คือกฎง่ายๆที่ฉันได้เห็นการทำงานจริง ๆ ซึ่งผู้คนสามารถยึดถือและผู้จัดการให้เวลา (การปรับโครงสร้างเหมือนการอดอาหาร: แน่นอน "แคลอรี่เข้า / ออก" เป็นสูตรลดน้ำหนัก แต่นั่นไม่ได้แปลเป็นอาหารที่ผู้คนจะต้องปฏิบัติตาม)

Refactor อย่างต่อเนื่องในขณะที่คุณทำงาน ใช้การพัฒนาแบบทดสอบขับเคลื่อนเพื่อให้คุณมีรอบสีแดง - เขียว - refactor หลายรอบตลอดทั้งวัน สร้างใหม่เฉพาะส่วนของรหัสที่คุณได้สัมผัส

เมื่อคุณมั่นใจในตัวเองมากขึ้นคุณสามารถเปลี่ยนแปลงจากระบบการปกครองนี้ได้

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

สำหรับเหตุผลทางเทคนิคมีหลายประการ

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