การเขียนโปรแกรมแบบโต้ตอบ ซึ่งนักพัฒนาสามารถแก้ไขและขยายโปรแกรมในขณะที่โปรแกรมกำลังทำงานอยู่ เป็นคุณสมบัติหลักของภาษาโปรแกรมอย่าง JavaScript และ Lisp มาอย่างยาวนาน ขณะนี้ชุมชนนักพัฒนาภาษา C กำลังสำรวจและแชร์แนวทางต่างๆ เพื่อให้ได้ความสามารถที่คล้ายกัน โดยมีนักพัฒนาหลายคนมีส่วนร่วมในการนำเสนอการใช้งานและข้อมูลเชิงลึกของตนเอง
แนวทาง Shared Library แสดงให้เห็นถึงความเป็นไปได้
วิธีการที่ได้รับการพูดถึงอย่างกว้างขวางที่สุดเกี่ยวข้องกับการสร้างแอปพลิเคชันเป็น shared libraries ที่สามารถโหลดใหม่แบบไดนามิกได้ เทคนิคนี้ซึ่งได้รับความนิยมจากซีรีส์การพัฒนาเกมของ Casey Muratori ชื่อ Handmade Hero ช่วยให้นักพัฒนาสามารถแก้ไขตรรกะของเกมได้โดยไม่ต้องรีสตาร์ทแอปพลิเคชันทั้งหมด แนวทางนี้ต้องการการพิจารณาการออกแบบอย่างระมัดระวัง โดยเฉพาะอย่างยิ่งในส่วนของการจัดการสถานะและ function pointers แต่ให้ผลตอบแทนด้านประสิทธิภาพการทำงานที่สำคัญในระหว่างการพัฒนา
ชุมชนได้ยอมรับแนวคิดนี้ โดยมีผู้สร้างเนื้อหาอย่าง Tsoding ผลิตวิดีโอเพื่อการศึกษาที่สาธิตการใช้งาน hot code reloading ทรัพยากรเหล่านี้ช่วยเผยแพร่ความรู้เกี่ยวกับเทคนิคนี้ไปยังบริบทอื่นนอกเหนือจากการเล่นเกมเดิม
ข้อกำหนดทางเทคนิคที่สำคัญ
- การจัดการ State: ไม่สามารถใช้ตัวแปรแบบ global หรือ static ในโค้ดที่สามารถโหลดใหม่ได้
- ข้อจำกัดของไลบรารี: การใช้ฟังก์ชัน C standard library ที่มี global state อย่างจำกัด
- การออกแบบ API: สัญลักษณ์ที่ส่งออกเพียงตัวเดียว (GAME_API struct) ที่ประกอบด้วย function pointer ทั้งหมด
- การจัดการข้อผิดพลาด: ต้องจัดการกับความล้มเหลวในการโหลดไลบรารีอย่างเหมาะสม
- ระบบไฟล์: ใช้การติดตาม inode เพื่อตรวจจับการอัปเดตไลบรารี
กลยุทธ์ทางเลือกเริ่มปรากฏขึ้น
ในขณะที่ shared libraries เป็นหนึ่งในแนวทาง นักพัฒนากำลังสำรวจโซลูชันสร้างสรรค์อื่นๆ แอปพลิเคชันที่ใช้เครือข่ายบางตัวใช้กลยุทธ์ที่แตกต่างไปโดยสิ้นเชิง - การดัมป์สถานะโปรแกรมไปยังไฟล์และเรียกใช้กระบวนการทั้งหมดใหม่ในขณะที่เก็บ network file descriptors เปิดไว้ วิธีการนี้ให้การอัปเดตแบบ zero-downtime และสามารถจัดการกับการรีบูตระบบได้อย่างสง่างามกว่าแนวทางที่ใช้ library
ข้อเสียหลักของวิธีนี้คือไลบรารีการเข้ารหัสส่วนใหญ่ไม่รองรับการ serializing สถานะของตน
อย่างไรก็ตาม แนวทางนี้เผชิญกับความท้าทายจากคอมโพเนนต์ที่มีสถานะอย่างไลบรารีการเข้ารหัส ซึ่งโดยทั่วไปไม่รองรับการ serialization ของสถานะ
โซลูชันที่ใช้ Interpreter ได้รับความสนใจ
ชุมชนยังได้เน้นย้ำถึงทางเลือกที่ใช้ interpreter เช่น TinyC ซึ่งสามารถทำงานเป็น C interpreter แทนที่จะต้องการการคอมไพล์และลิงก์ แนวทางนี้มีศักยภาพในการให้รอบการทำงานที่เร็วกว่าเนื่องจากขจัดขั้นตอนการ build ออกไปโดยสิ้เชิง แม้ว่าอาจมีการแลกเปลี่ยนด้านประสิทธิภาพในระหว่างการพัฒนา
แนวทางการ Hot Code Reloading ใน C
| วิธีการ | ข้อดี | ข้อเสีย | กรณีการใช้งานที่เหมาะสม |
|---|---|---|---|
| Shared Library | โหลดใหม่ได้เร็ว รักษาสถานะได้ | การจัดการสถานะซับซ้อน มีปัญหาเรื่อง function pointer | การพัฒนาเกม แอปพลิเคชันแบบโต้ตอบ |
| Process Re-exec | ไม่มี downtime จัดการกับการ reboot ได้ | มีปัญหาเรื่องสถานะการเข้ารหัส การตั้งค่าซับซ้อนกว่า | เซิร์ฟเวอร์เครือข่าย บริการที่ทำงานต่อเนื่องยาวนาน |
| Interpreter-based | ไม่ต้องผ่านขั้นตอนการคอมไพล์ การทำซ้ำเร็วที่สุด | มี overhead ด้านประสิทธิภาพ รองรับฟีเจอร์ของ C อย่างจำกัด | เครื่องมือพัฒนา การสร้างต้นแบบ |
แอปพลิเคชันในโลกจริงและความท้าทาย
นักพัฒนาได้แชร์ประสบการณ์การใช้งาน hot reloading ในบริบทต่างๆ ตั้งแต่เกมเอนจินไปจนถึงเครื่องมือพัฒนา นักพัฒนาคนหนึ่งสร้าง VS Code extension สำหรับการพัฒนาเกม Love2D ที่เปิดใช้งาน live coding แม้ว่าพวกเขาจะสังเกตว่าในขณะที่เทคโนโลยีทำงานได้ดี แต่ความท้าทายในการยอมรับนำไปสู่การยกเลิกโครงการ
การอภิปรายเผยให้เห็นว่าในขณะที่ hot code reloading ในภาษา C เป็นไปได้ทางเทคนิค การใช้งานที่ประสบความสำเร็จต้องการการพิจารณาอย่างระมัดระวังเกี่ยวกับการจัดการข้อผิดพลาด สถานะสำรอง และประสบการณ์ผู้ใช้ ชุมชนยังคงปรับปรุงเทคนิคเหล่านี้ต่อไป โดยแชร์ทั้งความสำเร็จและบทเรียนที่ได้เรียนรู้จากความพยายามที่ล้มเหลว
เมื่อนักพัฒนาจำนวนมากขึ้นทดลองกับแนวทางเหล่านี้ hot code reloading ในภาษา C กำลังพัฒนาจากเทคนิคเฉพาะกลุ่มไปสู่การปฏิบัติการพัฒนาที่เป็นกระแสหลักมากขึ้น โดยเฉพาะอย่างยิ่งในแอปพลิเคชันแบบโต้ตอบเช่นเกมและเครื่องมือพัฒนา
อ้างอิง: Interactive Programming in C