รหัสสปาเก็ตตี้คืออะไร

รหัสสปาเก็ตตี้ (spaghetti code) — คืออุปมาสำหรับอธิบายโค้ดที่มีโครงสร้างคล้ายจานสปาเก็ตตี้: เส้นแต่ละเส้น (บล็อกตรรกะ) พันกัน ติดกัน และแยกจากกันไม่ได้ ในโค้ดดังกล่าวไม่สามารถแยกเลเยอร์ โมดูล หรือคอมโพเนนต์ได้ — ทุกอย่างปะปนกันเป็นก้อนใหญ่ก้อนเดียว

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

จากข้อมูลของ IEEE (2022) ประมาณ 35% ของข้อผิดพลาดทั้งหมดในโปรเจกต์ขนาดใหญ่เกิดจากโครงสร้างโค้ดที่ยุ่งเหยิง ไม่ใช่ข้อผิดพลาดทางตรรกะของนักพัฒนา นักพัฒนาทำผิดไม่ใช่เพราะเข้าใจงานผิด แต่เพราะไม่สามารถติดตามกระแสการทำงานในรหัสสปาเก็ตตี้ได้

ความแตกต่างหลักจากแอนตี้แพทเทิร์นอื่นๆ

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

ประวัติของคำศัพท์และยุคของ goto

คำศัพท์ “spaghetti code” ปรากฏในยุค 1970s พร้อมกับการวิจารณ์คำสั่ง goto ในภาษาโปรแกรมมิ่งยุคแรก (BASIC, FORTRAN, COBOL) goto เป็นวิธีหลักในการควบคุมกระแสการทำงาน โปรแกรมประกอบด้วยลำดับของบรรทัดที่มีหมายเลข และ goto อนุญาตให้กระโดดไปยังบรรทัดใดก็ได้ สิ่งนี้สร้าง “ปม” ของการกระโดดที่ไม่สามารถคลายได้

ในปี 1968 Edsger Dijkstra ตีพิมพ์จดหมายที่มีชื่อเสียง “Go To Statement Considered Harmful” ซึ่งเป็นจุดเริ่มต้นของยุคการเขียนโปรแกรมแบบมีโครงสร้าง Dijkstra พิสูจน์ว่าอัลกอริทึมใดๆ สามารถทำได้โดยไม่ต้องใช้ goto โดยใช้เพียงสามโครงสร้าง: ลำดับ (sequence), การแยกสาขา (if) และการวนซ้ำ (while) สิ่งนี้กลายเป็นรากฐานของการเขียนโปรแกรมสมัยใหม่

การเขียนโปรแกรมแบบมีโครงสร้าง ไม่ได้กำจัดปัญหาทั้งหมด รหัสสปาเก็ตตี้ย้ายไปสู่อีกระดับ — แทนที่จะใช้ goto ทางกายภาพ นักพัฒนาเริ่มสร้าง “goto” เชิงตรรกะ: ตัวแปรโกลบอล, callback hell ใน JavaScript, สายโซ่การเรียกที่ซับซ้อน และการพึ่งพาโดยนัยระหว่างคอมโพเนนต์ ปัญหายังคงอยู่ มีเพียงรูปแบบที่เปลี่ยนไป

รูปแบบ goto สมัยใหม่

Callback hell ใน JavaScript, Promise ที่ซ้อนกันลึก, async/await โดยไม่มีการจัดการข้อผิดพลาด, อีเวนต์ที่ไม่มีใครรู้ว่าใครเป็นคนเรียกและเมื่อไหร่ — ทั้งหมดนี้คือรูปแบบสมัยใหม่ของรหัสสปาเก็ตตี้ แอนตี้แพทเทิร์นยังคงอยู่และแพร่หลาย เพียงแต่ตอนนี้มันไม่ได้ใช้คำสั่ง goto

สัญญาณของรหัสสปาเก็ตตี้ในโปรเจกต์

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

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

God-คลาส และ god-ฟังก์ชัน — สัญญาณที่สาม คลาสที่มี 2000+ บรรทัดที่รับผิดชอบทั้งบิสซิเนสลอจิก การแสดงผล และการทำงานกับข้อมูล — คือรหัสสปาเก็ตตี้ทั่วไป ฟังก์ชันที่รับพารามิเตอร์ 10 ตัวและทำสิ่งที่แตกต่างกัน 5 อย่าง — ก็เช่นกัน

การวินิจฉัยผ่านการทดสอบ

ถ้า คุณไม่สามารถเขียน unit-test สำหรับฟังก์ชันโดยไม่ต้องสร้าง mock-object 15 ตัว — นี่คือรหัสสปาเก็ตตี้ ถ้าการทดสอบโมดูลเดียวต้องเริ่มต้นโครงสร้างพื้นฐานทั้งหมดของแอปพลิเคชัน — นี่คือรหัสสปาเก็ตตี้ การไม่สามารถทดสอบได้เป็นตัวชี้วัดวัตถุประสงค์ของสถาปัตยกรรมที่ยุ่งเหยิง

ทำไมเส้นก๋วยเตี๋ยวจึงเกิดขึ้นในโค้ด

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

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

การละเมิด หลักการ SOLID — สาเหตุที่สาม โดยเฉพาะหลักการความรับผิดชอบเดียว (S) และการกลับด้านการพึ่งพา (D) เมื่อคลาสรับผิดชอบทุกอย่าง การพึ่งพาแข็งตัว และโมดูลถูกผูกติดกันแน่น — ผลลัพธ์คือรหัสสปาเก็ตตี้

ปัจจัยด้านเวลา

เดดไลน์ และวัฒนธรรม hotfix — ตัวเร่งปฏิกิริยาของรหัสสปาเก็ตตี้ เมื่อ “ต้องการตั้งแต่เมื่อวาน” นักพัฒนาใส่โค้ดในที่แรกที่เจอ โดยไม่คิดถึงสถาปัตยกรรม hotfix สิบครั้ง — และสถาปัตยกรรมของแอปพลิเคชันก็ถูกทำลาย

ผลกระทบของรหัสสปาเก็ตตี้

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

ประสิทธิภาพ ของทีมลดลงแบบเอกซ์โปเนนเชียล การวิจัยของ Microsoft Research (2023) แสดงให้เห็นว่าเวลาในการเพิ่มฟังก์ชันใหม่ในรหัสสปาเก็ตตี้เพิ่มขึ้นตามกฎกำลังสองเทียบกับขนาดของฐานโค้ด สำหรับสถาปัตยกรรมที่สะอาด การเพิ่มขึ้นนี้เป็นเชิงเส้น ความแตกต่างจะวิกฤตเมื่อมีโค้ด 50,000+ บรรทัด

ความปลอดภัย — อีกหนึ่งเหยื่อ ในรหัสสปาเก็ตตี้ มันง่ายที่จะพลาด exception ที่ไม่ได้รับการจัดการ, การตรวจสอบ input ที่ไม่ถูกต้อง หรือการรั่วไหลของข้อมูล การตรวจสอบความปลอดภัยในโปรเจกต์ที่มีสถาปัตยกรรมยุ่งเหยิงแทบเป็นไปไม่ได้ — การหาทุกจุดที่มีการใช้ input จากผู้ใช้นั้นไม่สมจริง

ผลกระทบต่อทีม

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

วิธีปรับโครงสร้างรหัสสปาเก็ตตี้

อย่างแรก — เริ่มต้นด้วยการแยกเลเยอร์ แบ่งโค้ดออกเป็นสามระดับ: presentation (UI, คอนโทรลเลอร์), business logic (บริการ, use cases) และ data access (รีพอสิทอรี, DAO) แม้แต่การแยกบางส่วนก็ช่วยปรับปรุงโครงสร้างทันทีและทำให้โค้ดทดสอบได้

อย่างที่สอง — นำ dependency injection มาใช้ แทนที่การสร้างการพึ่งพาโดยตรงด้วยการส่งผ่านคอนสตรัคเตอร์หรือพารามิเตอร์ สิ่งนี้ทำลายการเชื่อมต่อที่แข็งตัวระหว่างคอมโพเนนต์และช่วยให้ทดสอบแต่ละโมดูลแบบแยกส่วน

อย่างที่สาม — แยก god-คลาสและ god-ฟังก์ชัน แบ่งมันเป็นคลาสและเมธอดเล็กๆ ที่มีความรับผิดชอบเดียว ใช้แพทเทิร์น Facade เพื่อทำให้ระบบย่อยที่ซับซ้อนง่ายขึ้น จำไว้: คลาส 20 บรรทัดเข้าใจง่ายกว่าคลาส 2000 บรรทัด

// สปาเก็ตตี้ — ทุกอย่างในเมธอดเดียว
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// สถาปัตยกรรมที่สะอาด — เลเยอร์ที่แยกจากกัน
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

กลยุทธ์การปรับโครงสร้าง: วิธีการผ่าตัด

อย่า พยายามเขียนฐานโค้ดทั้งหมดใหม่ในครั้งเดียว — นั่นคือความล้มเหลวที่แน่นอน เลือกหนึ่งโมดูล เขียนเทสต์สำหรับมัน (characterization tests) ที่บันทึกพฤติกรรมปัจจุบัน แล้วค่อยปรับโครงสร้าง ทีละโมดูล คุณจะคลายเส้นสปาเก็ตตี้ได้

การป้องกันการเกิดเส้นก๋วยเตี๋ยว

การวางแผนสถาปัตยกรรม — พื้นฐานของการป้องกัน ก่อนเริ่มพัฒนา อนุมัติสไตล์สถาปัตยกรรม: MVC, MVVM, Clean Architecture, VIPER หรืออื่นๆ เขียน ADR (Architecture Decision Record) พร้อมเหตุผลในการเลือก กำหนดให้ต้องปฏิบัติตามสถาปัตยกรรมในการตรวจสอบโค้ด

หลักการ การกลับด้านการพึ่งพา (DIP) — เครื่องมือที่มีประสิทธิภาพในการต่อสู้กับรหัสสปาเก็ตตี้ โมดูลระดับสูงไม่ควรพึ่งพาโมดูลระดับต่ำ ทั้งสองควรพึ่งพานามธรรม Dependency Injection — การนำหลักการนี้ไปใช้ในทางปฏิบัติ

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

• สถาปัตยกรรม ก่อนโค้ด: อนุมัติแผนผังเลเยอร์และการพึ่งพา
• Dependency Injection เป็นแพทเทิร์นหลักในการเชื่อมต่อ
• TDD หรืออย่างน้อยมีความครอบคลุมการทดสอบสูง
• Code review ด้วยการตรวจสอบสถาปัตยกรรม ไม่ใช่แค่สไตล์
• การปรับโครงสร้าง เป็นประจำเป็นส่วนหนึ่งของกระบวนการพัฒนา

เครื่องมือในการต่อสู้กับรหัสสปาเก็ตตี้

SonarQube — ติดตามความซับซ้อนของไซโคลเมติก, ความลึกของการสืบทอด, ขนาดของเมธอด JDepend (Java) — วัดการพึ่งพาระหว่างแพคเกจ PhpMetrics — ให้ดัชนีการบำรุงรักษาสำหรับโปรเจกต์ PHP ติดตามเมตริกใน CI/CD — ป้องกันการเกิดเส้นก๋วยเตี๋ยว ดีกว่าต่อสู้กับมันทีหลัง