ทำไมหากโค้ดทำงานได้อยู่แล้ว อย่าแตะมันเด็ดขาด
โดย
วลีที่ว่า "หากโค้ดทำงานได้อยู่แล้ว ก็อย่าแตะมันเด็ดขาด" (หรือที่คล้ายกันในภาษาอังกฤษว่า "If it ain't broke, don't fix it") เป็นเหมือนคำพังเพยหรือแนวคิดที่หยั่งรากลึกในวงการพัฒนาซอฟต์แวร์มาช้านานครับ ไม่ได้มีที่มาจากตำราหรือบุคคลใดบุคคลหนึ่งโดยตรง แต่มันสะท้อน "ประสบการณ์จริง" และ "ความกลัว" ของโปรแกรมเมอร์หลายๆ คน โดยมีเหตุผลหลักๆ ดังนี้
1) ความเสี่ยงในการสร้างบั๊กใหม่ (Risk of Introducing New Bugs)
นี่คือเหตุผลที่ใหญ่ที่สุด การแก้ไขโค้ดส่วนหนึ่ง แม้จะดูเล็กน้อย อาจส่งผลกระทบที่ไม่คาดคิด (Side Effects) ไปยังส่วนอื่นๆ ของโปรแกรมที่เคยทำงานได้ดีอยู่แล้ว การแก้บั๊ก 1 จุด อาจนำไปสู่การเกิดบั๊กใหม่ๆ อีกหลายจุดได้ง่ายๆ โดยเฉพาะในระบบที่ซับซ้อน
2) ความซับซ้อน และ ความไม่เข้าใจโค้ดเดิม (Complexity and Lack of Understanding)
โค้ดที่ทำงานได้นั้น อาจเป็นโค้ดเก่า (Legacy Code) ที่เขียนมานานแล้ว มีความซับซ้อนสูง เอกสารประกอบอาจไม่มี หรือ ไม่อัปเดต คนที่เขียนคนแรกอาจไม่อยู่แล้ว การจะทำความเข้าใจโค้ดทั้งหมดให้ถ่องแท้เพื่อแก้ไขอย่างปลอดภัยนั้นใช้เวลา และ มีความเสี่ยงสูงมาก
3) การไม่มีระบบทดสอบอัตโนมัติที่ดี (Lack of Automated Tests)
หากไม่มีชุดการทดสอบ (Test Suite) ที่ครอบคลุม การเปลี่ยนแปลงโค้ดก็เหมือนการเดินในความมืด โปรแกรมเมอร์ไม่สามารถมั่นใจได้ 100% ว่าสิ่งที่แก้ไขไปจะไม่ทำให้ฟังก์ชันอื่นพัง การทดสอบด้วยมือ (Manual Testing) ก็ช้าและ อาจมีข้อผิดพลาด
4) ข้อจำกัดด้านเวลาและทรัพยากร (Time and Resource Constraints)
ในโลกธุรกิจ มักมีแรงกดดันให้พัฒนาฟีเจอร์ใหม่ๆ มากกว่าการกลับไปแก้ไขหรือปรับปรุง (Refactor) โค้ดเก่าที่ "ยังทำงานได้" การจะ "แตะ" โค้ดที่ยังใช้งานได้โดยไม่มีเหตุผลจำเป็นทางธุรกิจเร่งด่วน อาจถูกมองว่าไม่คุ้มค่ากับเวลา และ ทรัพยากร
5) โค้ดเหมือนกล่องดำ (Black Box Effect)
บางครั้งโค้ดบางส่วนทำงานได้ด้วยเหตุผลที่ซับซ้อน หรือ อาจเป็นผลจากการแก้ปัญหาเฉพาะหน้าในอดีตที่ไม่มีใครจำรายละเอียดได้แล้ว การไปยุ่งกับมันจึงรู้สึกเหมือนการเสี่ยงโดยไม่จำเป็น
6) การพึ่งพากันของระบบ (Dependencies)
โค้ดส่วนนั้นอาจถูกเรียกใช้งาน หรือ เชื่อมต่อกับระบบอื่นๆ หรือ ไลบรารีภายนอก การเปลี่ยนแปลงอาจทำให้ส่วนอื่นๆ ที่พึ่งพามันอยู่ทำงานผิดพลาดได้
- ★ข้อควรระวัง
ถึงแม้จะมีเหตุผลที่ทำให้โปรแกรมเมอร์ไม่อยากแตะโค้ดเก่า แต่การยึดติดกับแนวคิดนี้มากเกินไปก็เป็นอันตราย
○ เพราะอาจทำให้เกิดปัญหา หนี้ทางเทคนิค (Technical Debt) สะสม
○ ช่องโหว่ด้านความปลอดภัย (Security Vulnerabilities) ไม่ถูกแก้ไข
○ ประสิทธิภาพ (Performance) ไม่ได้รับการปรับปรุง หรือ โค้ดไม่สามารถปรับเปลี่ยนตามความต้องการใหม่ๆ ได้
ดังนั้น การตัดสินใจที่ดีที่สุดคือการ "ประเมินความเสี่ยง" เป็นกรณีไปครับ ถ้าจำเป็นต้องแก้เพื่อแก้ไขบั๊กสำคัญ ปิดช่องโหว่ หรือ ปรับปรุงประสิทธิภาพ ก็ต้องทำอย่างระมัดระวัง และ มีแผนการทดสอบที่ดีรองรับ
✏️ Shoper Gamer
Credit :
👇
- ●https://youtu.be/7cCO49Z-irY?si=EclO52qdW9NC0i0H
- ●https://medium.com/codex/if-software-isnt-broke-you-still-have-to-fix-it-9773d5235448
- ●https://zhiminzhan.medium.com/questioning-if-it-aint-broke-don-t-fix-it-in-software-development-a4df62671afc
- 2
ดูเพิ่มเติมในซีรีส์
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2025 Blockdit
