ใครบ้างที่มีปัญหาการปรับโครงสร้างใหม่ [ปิด]

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

ฉันสนุกกับช่วงเวลาเหล่านี้เมื่อพวกเขาเกิดขึ้นกับฉัน

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

ไม่ว่าจะด้วยวิธีใดการเรียนรู้จากความผิดพลาดของคุณเป็นสิ่งที่ยอดเยี่ยม!

ต่อไปนี้เป็นกฎบางประการที่จะ จำกัด กิจกรรมนี้และทำให้มีประสิทธิผลมากขึ้น:

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

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

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

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

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

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

ฉันอยากจะแนะนำว่าอย่าพึ่งขึ้นอยู่กับความรู้สึกหรือกลิ่นรหัส

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

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

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

ไม่ต้องสงสัยเลยว่าฉันตกหลุมพรางนี้ แต่การปรับโครงสร้างบางอย่างมีความสำคัญต่อการสนับสนุน / การดีบักในอนาคต

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

ฉันตกหลุมกับดักนี้เมื่อฉันเรียนรู้ภาษาหรือเทคโนโลยีเป็นครั้งแรก ตัวอย่างเช่นเมื่อคุณเรียนรู้จาวาครั้งแรกลองจินตนาการว่าคุณเขียนเว็บแอพด้วย servlet โดยคิดว่าเป็นวิธีที่ถูกต้อง จากนั้นคุณก็รู้ว่ามี jsp และคุณคิดว่าโอ้มันใหม่กว่านั้นอาจจะใช่ จากนั้นเมื่อคุณผ่านไปครึ่งทางคุณจะพบกับ Struts และบางอย่างของ EJB หลังจากนั้นคุณจะพบกับฤดูใบไม้ผลิ (ตาม xml) หลังจากนั้นคุณจะพบคำอธิบายประกอบ @MVC ที่ยอดเยี่ยมหลังจากนั้นคุณก็พบว่า verbose ทั้งหมดเกินไป ทางเลือกระหว่าง groovy / grails และ scala / lift! นี่เป็นสิ่งที่สมบูรณ์แบบสำหรับโครงการส่วนบุคคลเนื่องจากจุดที่มักจะเรียนรู้และไม่จำเป็นต้องมีกำหนดเวลา

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

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

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