ฮาร์ดโค้ดในการเขียนโปรแกรม: คืออะไร สาเหตุ และวิธีหลีกเลี่ยง

ฮาร์ดโค้ดในการเขียนโปรแกรมคืออะไร

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

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

ตามการศึกษาVeracode State of Software Security 2024 ประมาณ 23% ของช่องโหว่ทั้งหมดในแอปพลิเคชันเชิงพาณิชย์เกี่ยวข้องกับข้อมูลรับรองที่ถูกฮาร์ดโค้ด ทำให้การต่อสู้กับฮาร์ดโค้ดไม่ใช่เพียงเรื่องความสะดวกสบาย แต่เป็นงานด้านความปลอดภัยของข้อมูลที่สำคัญ

นิยามของฮาร์ดโค้ดอย่างง่าย

ค่าที่ถูกฮาร์ดโค้ดคือตัวเลข สตริง หรือการตั้งค่าใดๆ ที่เขียนลงในโค้ดโดยตรงแทนที่จะโหลดจากการกำหนดค่า ตัวอย่างเช่น หากนักพัฒนาเขียน `connectionTimeout = 30` ภายในคลาสการเชื่อมต่อฐานข้อมูล — นั่นคือฮาร์ดโค้ด หากเขาอ่านค่าระยะเวลารอจากตัวแปรสภาพแวดล้อมหรือไฟล์กำหนดค่า — นั่นคือวิธีการที่ถูกต้อง

ที่มาของคำ

คำว่าฮาร์ดโค้ดมาจากคำภาษาอังกฤษ hard code ที่แปลว่า “โค้ดที่แข็ง” ในสภาพแวดล้อมที่พูดภาษาไทย ก็ใช้คำว่า “การเขียนโค้ดแบบตายตัว” หรือ “ค่าคงที่” เช่นกัน แตกต่างจากการกำหนดค่าที่ยืดหยุ่น ฮาร์ดโค้ดถูก “เย็บ” ไว้ในไฟล์ปฏิบัติการอย่างแท้จริง และไม่สามารถเปลี่ยนแปลงได้หากไม่สร้างใหม่

ทำไมฮาร์ดโค้ดจึงถือเป็นแนวปฏิบัติที่ไม่ดี

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

ในAgileและDevOps ซึ่งต้องการการปรับใช้อย่างรวดเร็วในสภาพแวดล้อมต่างๆ — การพัฒนา การทดสอบ การผลิต — ฮาร์ดโค้ดกลายเป็นอุปสรรคที่ข้ามไม่ได้ ทีมต้องแก้ไขโค้ดก่อนการปรับใช้แต่ละครั้งหรือใช้แพชแบบ manually ซึ่งขัดต่อหลักการของการส่งมอบอย่างต่อเนื่อง

การศึกษาของมหาวิทยาลัยเคมบริดจ์ (2023) แสดงให้เห็นว่าโครงการที่มีระดับฮาร์ดโค้ดสูงมีข้อบกพร่องในการเผยแพร่มากกว่า 47% และใช้เวลาในการเปลี่ยนแปลงมากกว่า 2.3 เท่า สิ่งนี้ยืนยันว่าต้นทุนการบำรุงรักษาโค้ดที่ถูกฮาร์ดโค้ดสูงกว่าการประหยัดเวลาในระยะเริ่มต้นของการพัฒนาอย่างมีนัยสำคัญ

ความสามารถในการปรับขนาดและการพกพา

แอปพลิเคชันที่มีพารามิเตอร์ถูกฮาร์ดโค้ดนั้นยากที่จะปรับให้เข้ากับแพลตฟอร์มต่างๆ ตัวอย่างเช่น เส้นทางไฟล์ `C:\Users\admin\data.txt` จะไม่ทำงานบนเซิร์ฟเวอร์ Linux และขนาดฟอนต์ 14pt อาจดูแตกต่างกันบนอุปกรณ์ที่มีความหนาแน่นของพิกเซลต่างกัน

การบำรุงรักษาโค้ด

เมื่อฮาร์ดโค้ดกระจายอยู่ทั่วโครงการ นักพัฒนาต้องค้นหาแต่ละค่าแบบ manually โดยใช้ grep หรือการค้นหาของ IDE ซึ่งทำให้การพัฒนาช้าลง เพิ่มโอกาสในการพลาดค่าที่จำเป็น และเปิดทางให้เกิดบั๊ก ในขณะเดียวกัน สมาชิกทีมใหม่ใช้เวลามากขึ้นอย่างมากในการทำความเข้าใจ “เลขมหัศจรรย์” และสตริง

ค่าใดบ้างที่ถูกฮาร์ดโค้ดบ่อยที่สุด

รหัสผ่านและข้อมูลรับรองเป็นประเภทฮาร์ดโค้ดที่อันตรายที่สุด นักพัฒนามักบันทึกรหัสผ่านฐานข้อมูล คีย์ API ของบริการบุคคลที่สาม และโทเค็นการอนุญาตลงในโค้ดโดยตรงเพื่อความสะดวกในการพัฒนาท้องถิ่น แต่ลืมแยกออกก่อน commit สิ่งนี้นำไปสู่การรั่วไหลในที่เก็บสาธารณะ

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

เลขมหัศจรรย์ — ค่าคงที่ที่เป็นตัวเลขโดยไม่มีคำอธิบาย ตัวอย่างเช่น `price * 0.85` แทน `price * DISCOUNT_RATE` ผู้อ่านโค้ดไม่เข้าใจว่า 0.85 หมายถึงอะไร นี่คือตัวอย่างคลาสสิกของฮาร์ดโค้ดที่ Martin Fowler อธิบายไว้ในหนังสือ “Refactoring” (1999)

สตริงมหัศจรรย์

ลิเทอรัลสตริงที่ซ้ำกันในส่วนต่างๆ ของโปรแกรมเป็นอีกประเภทหนึ่งของฮาร์ดโค้ดที่พบบ่อย ตัวอย่างเช่น คีย์พจนานุกรม ส่วนหัว HTTP ชื่อมุมมองในแอปพลิเคชัน iOS หากสตริงเปลี่ยนในที่หนึ่งแต่ยังคงเดิมในอีกที่หนึ่ง แอปพลิเคชันจะเสีย วิธีแก้คือแยกสตริงออกเป็นค่าคงที่หรือไฟล์แปลภาษา

การกำหนดค่าสภาพแวดล้อม

โหมดแอปพลิเคชัน (ดีบัก/รีลีส) การตั้งค่าการบันทึก ที่อยู่เซิร์ฟเวอร์ SMTP — พารามิเตอร์ทั้งหมดนี้ควรอยู่ภายนอก หากถูกฮาร์ดโค้ด เมื่อย้ายไปยังเซิร์ฟเวอร์อื่น แอปพลิเคชันอาจไม่เริ่มทำงานหรือเริ่มมีพฤติกรรมที่คาดเดาไม่ได้

ความเสี่ยงด้านความปลอดภัยของการใช้ฮาร์ดโค้ด

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

มาตรฐานOWASP (โครงการความปลอดภัยแอปพลิเคชันเว็บแบบเปิด) รวมข้อมูลรับรองที่ถูกฮาร์ดโค้ดในหมวด A04:2021 — การออกแบบที่ไม่ปลอดภัย OWASP แนะนำว่าไม่ควรเก็บรหัสผ่าน โทเค็น หรือคีย์ในซอร์สโค้ด ให้ใช้บริการจัดการความลับเฉพาะทางแทน: HashiCorp Vault, AWS Secrets Manager หรือ Azure Key Vault

การตรวจสอบความปลอดภัยที่ดำเนินการโดยPositive Technologies (2024) แสดงให้เห็นว่า 78% ของแอปพลิเคชันมือถือที่ทดสอบมีคีย์หรือโทเค็นที่ถูกฮาร์ดโค้ดอย่างน้อยหนึ่งรายการ สำหรับแอปพลิเคชันเว็บ ตัวเลขนี้คือ 62% ช่องโหว่ส่วนใหญ่สามารถกำจัดได้โดยเพียงแยกข้อมูลออกเป็นไฟล์กำหนดค่า

# hardcoded secrets — unsafe
password = "supersecret123"
api_key = "sk-abc123def456"

# safe approach — read from env vars
import os
password = os.getenv("DB_PASSWORD")
api_key = os.getenv("API_KEY")

การรั่วไหลผ่านระบบควบคุมเวอร์ชัน

Gitเก็บประวัติคอมมิตทั้งหมดไว้ หากรหัสผ่านที่ถูกฮาร์ดโค้ดเข้าไปในที่เก็บ มันจะยังคงอยู่ในประวัติแม้หลังจากถูกลบออกจากเวอร์ชันปัจจุบันแล้วก็ตาม เครื่องมืออย่าง git-secrets และ truffleHog ช่วยตรวจจับการรั่วไหลดังกล่าว แต่ควรป้องกันตั้งแต่ขั้นตอนการตรวจสอบโค้ดจะดีกว่า

ข้อกำหนดด้านกฎระเบียบ

มาตรฐาน PCI DSS, GDPR และ HIPAA ห้ามเก็บข้อมูลที่เป็นความลับในซอร์สโค้ดโดยตรง การใช้ฮาร์ดโค้ดอาจนำไปสู่ผลทางกฎหมายและค่าปรับ โดยเฉพาะในภาคการเงินและการแพทย์

วิธีหลีกเลี่ยงฮาร์ดโค้ดในโครงการ

ขั้นตอนแรกในการกำจัดฮาร์ดโค้ดคือการตระหนักรู้ในระดับทีม การตรวจสอบโค้ดควรรวมการตรวจสอบค่าที่ถูกฮาร์ดโค้ดด้วย ตั้งค่า linter หรือตัววิเคราะห์แบบ static ที่จะเน้นฮาร์ดโค้ดที่อาจเกิดขึ้น สำหรับ TypeScript, ESLint ด้วยกฎ no-hardcoded-credentials ทำงานได้ดี สำหรับ Python, Bandit

ขั้นตอนที่สองคือการใช้รูปแบบ Configuration as Code พารามิเตอร์ทั้งหมดที่อาจแตกต่างกันในสภาพแวดล้อมต่างๆ ควรเก็บในตัวแปรสภาพแวดล้อมหรือไฟล์กำหนดค่า ไลบรารีอย่าง dotenv (Node.js), python-decouple (Python) หรือ Spring Cloud Config (Java) ทำให้วิธีการนี้เป็นมาตรฐาน

ขั้นตอนที่สามคือการใช้บริการจัดการการกำหนดค่า: Consul, etcd, Zookeeper สำหรับโครงการคลาวด์ AWS Parameter Store, Google Cloud Secret Manager หรือ Azure App Configuration เหมาะสม ในสถาปัตยกรรมไมโครเซอร์วิส การจัดการการกำหนดค่าแบบรวมศูนย์มีความสำคัญอย่างยิ่ง

• ตัวแปรสภาพแวดล้อม — สำหรับความลับและข้อมูลที่ละเอียดอ่อน
• ไฟล์ .env — สำหรับการพัฒนาท้องถิ่น
• คลาสกำหนดค่า — ด้วยการอ่านจากแหล่งภายนอก
• Feature Toggles — สำหรับเปิด/ปิดฟังก์ชันการทำงาน
• การปรับภาษา — สำหรับทรัพยากรสตริง

แนวทางปฏิบัติที่ดีที่สุด

จัดทำเอกสารพารามิเตอร์การกำหนดค่าแต่ละรายการ: วัตถุประสงค์ ค่าที่อนุญาต ค่าเริ่มต้น ใช้การตรวจสอบ schema สำหรับการกำหนดค่า — ซึ่งช่วยตรวจจับข้อผิดพลาดเมื่อเริ่มต้นแอปพลิเคชัน สร้างไฟล์ .env.example พร้อมตัวแปรที่จำเป็นทั้งหมด แต่ไม่มีค่าจริง

ตัวอย่างการรีแฟคเตอร์ฮาร์ดโค้ด

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

// before refactoring — hardcoded values
const response = await fetch("https://api.example.com/v1/users", {
  timeout: 5000,
  headers: { "Authorization": "Bearer sk-abc" }
});

// after refactoring — config driven
const config = {
  apiUrl: process.env.API_URL,
  timeout: parseInt(process.env.API_TIMEOUT || "30000"),
  authToken: process.env.AUTH_TOKEN
};

const response = await fetch(config.apiUrl, {
  timeout: config.timeout,
  headers: { "Authorization": "Bearer " + config.authToken }
});

การรีแฟคเตอร์ใน Java

ในJava ฮาร์ดโค้ดมักปรากฏในรูปแบบของสตริงการเชื่อมต่อฐานข้อมูล การใช้ Spring Boot กับ application.yml แก้ปัญหานี้: ไฟล์มีโปรไฟล์สำหรับสภาพแวดล้อมต่างๆ และโค้ดอ่านค่าผ่านคำอธิบายประกอบ @Value

// hardcoded — Java example
class DatabaseConnection {
    private String url = "jdbc:mysql://localhost:3306/mydb";
    private String user = "admin";
    private String password = "pass123";
}

// proper config via Spring Boot
@Value("${db.url}")
private String url;

ฮาร์ดโค้ดในภาษาโปรแกรมมิ่งต่างๆ

วิธีการต่อสู้กับฮาร์ดโค้ดขึ้นอยู่กับภาษาและระบบนิเวศ ในภาษาที่ถูกแปลความ (Python, JavaScript, Ruby) การกำหนดค่ามักเก็บในตัวแปรสภาพแวดล้อมหรือไฟล์ .env ในภาษาที่ถูกคอมไพล์ (Java, C#, Go) เก็บในไฟล์กำหนดค่า YAML, JSON, XML หรือทรัพยากรที่ฝังอยู่

ในPython ไลบรารี python-decouple เป็นที่นิยม — อ่านการกำหนดค่าจากไฟล์ .env และให้ getter แบบระบุชนิด ในGo ใช้ Viper — ไลบรารีที่มีประสิทธิภาพสำหรับทำงานกับการกำหนดค่าจากแหล่งต่างๆ ในSwift สำหรับการพัฒนา iOS การกำหนดค่าจะถูกแยกไปยัง Info.plist หรือไฟล์ Configuration แยกต่างหาก

เครื่องมือวิเคราะห์แบบ static เช่น SonarQube, ESLint, Pylint สามารถตรวจจับค่าที่ถูกฮาร์ดโค้ดโดยอัตโนมัติ SonarQube มีกฎในตัวสำหรับค้นหาเลขมหัศจรรย์และสตริงในโค้ดในภาษาต่างๆ การตั้งค่าการตรวจสอบดังกล่าวในไปป์ไลน์ CI/CD เป็นวิธีที่ดีที่สุดในการป้องกันไม่ให้ฮาร์ดโค้ดใหม่เกิดขึ้น

การตรวจหาฮาร์ดโค้ดอัตโนมัติ

ฮุค Git pre-commitสามารถเรียกสคริปต์ที่ตรวจสอบคอมมิตว่ามีความลับที่ถูกฮาร์ดโค้ดหรือไม่ เครื่องมือ git-secrets สแกนคอมมิตเพื่อหาค่าที่ตรงกับนิพจน์ปกติสำหรับรหัสผ่าน คีย์ และโทเค็น TruffleHog และ Gitleaks ไปไกลกว่านั้น — ตรวจสอบประวัติ git ทั้งหมดเพื่อหารั่วไหล