มีคำพูดเก่า ๆ ในการพัฒนาซอฟต์แวร์ ฉันเคยได้ยินมาหลายครั้งในอาชีพของฉัน ...

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

คุณอาจประสบปัญหาในการเพิ่มประสิทธิภาพโค้ดเก่า

แต่คุณควรล้างรหัสเก่าเมื่อทำได้!

คุณตัดสินใจอย่างไร - ปล่อยไว้หรือแก้ไข

รหัสของฉันใช้งานได้

มี GIF ตลกๆ โผล่ขึ้นมาบน Reddit ในตอนนี้..

เป็นการตอกย้ำความจริงที่ว่าเรามักจะรู้ว่ารหัสของเราไม่เหมาะกับโดเมน!

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

แม้ในเวลาที่คุณเขียนโค้ด อาจดูเหมือนไม่ใช่ทางออกที่ดีที่สุด

จะทำอย่างไร?

ชั่งน้ำหนักตัวเลือกของคุณ

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

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

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

ไม่ง่ายอย่างที่คิด

คุณมักจะพบว่ารหัสพื้นฐานมีความซับซ้อนด้วยเหตุผล

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

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

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

ฉันจะบอกว่าให้ถือว่าจะใช้เวลาสองเท่าเท่าที่คุณคิด

ก็ต้องถามว่า “คุ้มไหม”

คำถามที่ต้องพิจารณา

ต่อไปนี้คือสิ่งที่ควรพิจารณาก่อนที่คุณจะดำเนินการปรับโครงสร้างครั้งใหญ่:

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

แต่ฉันเคยอยู่ในทีมที่ความพยายามในการ Refactor อันธพาลได้ดูดเอาเวลา พลังงาน และความสนใจของนักพัฒนาของเราไป ทั้งหมดเพื่อประโยชน์ไม่มาก.

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

รายการรายวัน

ฉันช่วยนักพัฒนาซอฟต์แวร์สร้างอาชีพที่มีความหมายโดยมีวัตถุประสงค์

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

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

นักพัฒนาซอฟต์แวร์อีก 2,000 คนได้รับโพสต์รายวันของฉันส่งตรงไปยังกล่องจดหมายของพวกเขา

เข้าร่วมรายการรายวันและเข้าถึงเนื้อหาที่ดีที่สุดของฉันได้ทันที!

—

เข้าร่วมสื่อในราคา $5 — เข้าถึงสื่อทั้งหมด + สนับสนุนฉันและคนอื่นๆ!