โค้ดที่ตายแล้วและโค้ดซอมบี้ในการพัฒนา: คืออะไร สาเหตุ และการค้นหา

โค้ดที่ตายแล้วคืออะไร?

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

ตัวอย่างคลาสสิกของโค้ดที่ตายแล้ว: ตัวแปรที่ถูกกำหนดค่าแต่ไม่เคยถูกอ่าน ฟังก์ชันหรือเมธอดที่ไม่ถูกเรียกที่ใด สาขาเงื่อนไขที่ไม่เคยเป็นจริง (if(false)) ลูปที่เนื้อหาไม่ถูกดำเนินการแม้แต่ครั้งเดียว

ตามรายงาน SonarQube State of Code Quality (2025) ประมาณ 15 เปอร์เซ็นต์ของคำเตือนทั้งหมดในโปรเจกต์ Java เชิงพาณิชย์เกี่ยวข้องกับเมธอดและฟิลด์ private ที่ไม่ได้ใช้งาน ในโปรเจกต์ JavaScript สัดส่วนของโค้ดที่ไม่ได้ใช้งานอาจสูงถึง 30 เปอร์เซ็นต์เนื่องจากลักษณะไดนามิกของภาษาและความอุดมสมบูรณ์ของไลบรารีของบุคคลที่สาม

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

ความแตกต่างระหว่างโค้ดที่ตายแล้วและโค้ดซอมบี้

โค้ดซอมบี้ (zombie code) เป็นกรณีพิเศษของโค้ดที่ตายแล้วซึ่งแตกต่างด้วยบริบททางประวัติศาสตร์ โค้ดซอมบี้เคยทำงาน หลังจากเปลี่ยนแปลงในระบบกลับไม่สามารถเข้าถึงได้ แต่มันไม่ถูกลบ แต่ถูกเก็บไว้ «เผื่อไว้»

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

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

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

สาเหตุของการเกิดโค้ดที่ตายแล้ว

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

สาเหตุที่สอง — การทดสอบ A/B และฟีเจอร์ toggle เงื่อนไขการเปิดใช้งานฟีเจอร์ใหม่อาจคงที่เมื่อเวลาผ่านไป (ตัวอย่างเช่น true เสมอ) แต่สาขา else ที่มีตรรกะทางเลือกยังคงอยู่ในโค้ด นักพัฒนากลัวที่จะลบมันเพราะเกรงว่าจะทำลายระบบโดยไม่ได้ตั้งใจหาก toggle ถูกเปิดกลับ

สาเหตุที่สาม — การสร้างอัตโนมัติและการคัดลอกวาง ตัวสร้างโค้ด (IDE, เอ็นจินเทมเพลต) สร้างเทมเพลตพร้อมเมธอดที่นักพัฒนาไม่กรอกหรือไม่ใช้ โค้ดที่คัดลอกจากโปรเจกต์อื่นมักมีบล็อกทั้งหมดที่ไม่เกี่ยวข้องกับบริบทใหม่

สาเหตุที่สี่ — ความกลัวในการลบ ในโปรเจกต์ขนาดใหญ่ นักพัฒนากลัวที่จะลบโค้ดเพราะพวกเขาไม่แน่ใจว่ามันไม่ได้ถูกใช้ที่ใดจริง ๆ ความกลัวนี้รุนแรงขึ้นจากระบบทดสอบที่อ่อนแอ: หากไม่มีการตรวจสอบอัตโนมัติ การลบอาจนำไปสู่ข้อบกพร่องที่ถูกค้นพบในสภาพแวดล้อมการผลิตเท่านั้น

อันตรายของโค้ดที่ตายแล้ว

โค้ดที่ตายแล้ว ส่งผลโดยตรงต่อคุณภาพของโปรเจกต์สี่ด้าน: ประสิทธิภาพการบิวด์ ขนาดสิ่งประดิษฐ์ ภาระทางปัญญาของทีม และความน่าเชื่อถือของการรีแฟคเตอร์

เวลาในการคอมไพล์เพิ่มขึ้น: คอมไพเลอร์ประมวลผลไฟล์ที่ไม่ได้ใช้ วิเคราะห์ dependencies และสร้างไบต์โค้ดหรือโค้ดเครื่องสำหรับส่วนที่จะไม่ถูกเรียกใช้ ในโปรเจกต์ขนาดใหญ่ สิ่งนี้เพิ่มนาทีให้กับการบิวด์แต่ละครั้ง สำหรับภาษาที่ถูกแปลความ (JavaScript, Python) เวลาโหลดโมดูลและการใช้หน่วยความจำเพิ่มขึ้น

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

ภาระทางปัญญา เป็นปัจจัยที่แพงที่สุด แต่ละฟังก์ชันที่ไม่ได้ใช้ต้องการความสนใจเมื่ออ่านโค้ด นักพัฒนาใช้พลังงานทางจิตเพื่อทำความเข้าใจว่าโค้ดนี้มีอยู่ทำไมและถูกเรียกที่ไหน การวิจัยของ Developer Productivity Lab (2025) แสดงให้เห็น: การลบ 20 เปอร์เซ็นต์ของโค้ดที่ตายแล้วช่วยลดเวลาในการเริ่มงาน (onboarding time) โดยเฉลี่ย 18 เปอร์เซ็นต์

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

เครื่องมือค้นหาโค้ดที่ตายแล้ว

การค้นหาโค้ดที่ตายแล้วทำด้วยสองวิธีหลัก: การวิเคราะห์แบบสแตติก (โดยไม่เรียกใช้โปรแกรม) และการวิเคราะห์แบบไดนามิก (การทำโปรไฟล์ความครอบคลุมในรันไทม์) แต่ละวิธีมีประสิทธิภาพสำหรับโค้ดที่ตายแล้วประเภทต่างกัน

ตัววิเคราะห์แบบสแตติกรองรับภาษาการเขียนโปรแกรมยอดนิยมทั้งหมด สำหรับ Java และ Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs สำหรับ JavaScript และ TypeScript — ESLint พร้อมกฎ no-unused-vars และ no-unused-modules สำหรับ Swift — SwiftLint พร้อมกฎ unused_declaration สำหรับ Python — pylint พร้อมตัวเลือก unused-import และ vulture สำหรับการค้นหาเชิงลึก

ตัวอย่างการค้นหาใน Kotlin ผ่าน ProGuard

// build.gradle.kts - การกำหนดค่า ProGuard สำหรับ Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro - เก็บเฉพาะคลาสที่จำเป็น
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard ไม่เพียงลบคลาสและเมธอดที่ไม่ได้ใช้ แต่ยังย่อชื่อในบิวด์ที่เผยแพร่ บิวด์ที่เปิดใช้ ProGuard จะแสดงโดยอัตโนมัติว่าคลาสและเมธอดใดถูกพิจารณาว่าไม่ได้ใช้ — ในรายงาน usage.txt จะแสดงโค้ดที่ถูกลบทั้งหมด

การวิเคราะห์แบบไดนามิกผ่านความครอบคลุมของการทดสอบ

เครื่องมือความครอบคลุมของโค้ด (JaCoCo สำหรับ Java, XCTest coverage สำหรับ Swift, Istanbul สำหรับ JavaScript) แสดงว่าบรรทัดและสาขาใดถูกดำเนินการระหว่างการทดสอบ เมธอดที่มีความครอบคลุมเป็นศูนย์ — ผู้สมัครสำหรับโค้ดที่ตายแล้ว อย่างไรก็ตามการขาดความครอบคลุมไม่รับประกันว่าโค้ดจะไม่ถูกเรียกในสภาพแวดล้อมการผลิต — เพื่อความแน่ใจสมบูรณ์ให้ใช้การวิเคราะห์ทั้งแบบสแตติกและไดนามิกร่วมกัน

กำหนดค่าไปป์ไลน์ CI ของคุณให้บิวด์ล้มเหลวเมื่อเกินเกณฑ์ของการประกาศที่ไม่ได้ใช้ Quality Gate ของ SonarQube ด้วยกฎ «สัดส่วนของโค้ด private ที่ไม่ได้ใช้ไม่เกิน 3%» ป้องกันการสะสมของโค้ดที่ตายแล้วในระดับกระบวนการพัฒนา

วิธีลบโค้ดที่ตายแล้วอย่างปลอดภัย

กระบวนการลบโค้ดที่ตายแล้ว ประกอบด้วยสี่ขั้นตอน: ค้นหา ตรวจสอบ ลบ ตรวจสอบอีกครั้ง การข้ามขั้นตอนใด ๆ เพิ่มความเสี่ยงของการถดถอย

ขั้นตอนแรก — ค้นหาผู้สมัคร ผ่านตัววิเคราะห์แบบสแตติก รับรายงานของการประกาศที่ไม่ได้ใช้: ฟังก์ชัน คลาส ตัวแปร import กรองผลบวกปลอม — ตัววิเคราะห์บางครั้งผิดพลาดในกรณีของ reflection การโหลดคลาสแบบไดนามิก หรือการเรียกที่ซ่อนผ่าน serialization

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

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

// before - โค้ดที่ตายแล้วและโค้ดซอมบี้ในไฟล์เดียวกัน
int calculateV1(int price) { // ไม่ได้ถูกเรียกที่ใด
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// after - โค้ดที่ตายแล้วถูกลบ โค้ดซอมบี้ถูกทำความสะอาด
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

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

ใช้กฎ: ไม่มี pull request ใดควรมีโค้ดที่ตายแล้วใหม่ เพิ่ม linter ใน hooks pre-commit ที่บล็อกการคอมมิตเมื่อมีตัวแปรหรือ import ที่ไม่ได้ใช้ การป้องกันถูกกว่าการทำความสะอาดเสมอ