ซอฟต์แวร์ที่มีเลือดเย็น
- ในปี 2004 ผู้เขียนซึ่งเรียนสาขาวิทยาการคอมพิวเตอร์ ได้เห็นอาจารย์นำลูกเต่าน้ำจืดทาสีที่ถูกแช่แข็งมาให้ดูระหว่างการบรรยายวิชาประวัติศาสตร์ธรรมชาติ
- เต่าชนิดนี้เป็นหนึ่งในไม่กี่สปีชีส์ที่สามารถอยู่รอดได้แม้อยู่ในสภาพถูกแช่แข็ง เป็นสัตว์เลือดเย็นที่สามารถปรับการเผาผลาญเมื่ออุณหภูมิต่ำลง
- ระหว่างการบรรยาย ผู้เขียนได้สังเกตเห็นเต่าค่อย ๆ ขยับและกลับมามีชีวิตอีกครั้ง ทำให้เข้าใจสัตว์เลือดเย็นได้ลึกซึ้งยิ่งขึ้น
ทวิลักษณ์ของโครงการซอฟต์แวร์
- โครงการซอฟต์แวร์เองก็อาจแบ่งได้เป็นโครงการแบบเลือดอุ่นและเลือดเย็น
- โครงการเลือดอุ่นต้องการกิจกรรมอย่างต่อเนื่อง และหากกิจกรรมนั้นหยุดลงก็จะเกิดปัญหา
- โครงการเลือดเย็นแม้จะเงียบไปช่วงหนึ่ง แต่เมื่อกลับมาทำต่อก็สามารถเริ่มจากจุดเดิมได้ทันที
ซอฟต์แวร์เลือดเย็นของบล็อก
- ซอฟต์แวร์ที่ขับเคลื่อนบล็อกของผู้เขียนเป็นซอฟต์แวร์เลือดเย็น
- โครงการนี้เริ่มต้นเมื่อ 12 ปีก่อน มีความเรียบง่าย ไม่พึ่งพาบริการภายนอก และรวม dependency ทั้งหมดไว้ใน repository ของโครงการ
- นอกจากการปรับปรุงเล็กน้อยไม่กี่อย่างแล้ว มันก็ทำงานได้ดีโดยแทบไม่ต้องแก้ไข และคาดว่าจะยังทำงานต่อไปได้อีก 12 ปี
ความเห็นของ GN⁺
- แนวคิดเรื่องซอฟต์แวร์เลือดเย็นส่งผลสำคัญต่อความยั่งยืนและการบำรุงรักษาของโครงการ
- บทความนี้ให้มุมมองเชิงลึกว่าการเลือกเทคโนโลยีสแตกส่งผลต่ออายุขัยของโครงการอย่างไร
- ประสบการณ์ของผู้เขียนมอบบทเรียนแก่ผู้พัฒนาซอฟต์แวร์เกี่ยวกับวิธีสร้างระบบที่มั่นคงในระยะยาว
1 ความคิดเห็น
ความเห็นจาก Hacker News
ใน ecosystem ของ Node และ JavaScript มีเว็บเฟรมเวิร์ก Express อยู่ สายเวอร์ชันหลักปัจจุบันคือ 4.x.x ซึ่งมีอายุมากกว่า 10 ปีแล้ว และมียอดดาวน์โหลดมากกว่า 17 ล้านครั้งต่อสัปดาห์ แม้จะขาดบางฟีเจอร์และประสิทธิภาพอาจไม่ใช่ระดับสูงสุด แต่ก็ช่วยให้พัฒนาได้รวดเร็วและเสถียร วางแผนระยะยาวได้โดยไม่ต้องกังวลเรื่องการเปลี่ยน API หรือการขาด security patch มากนัก จึงเป็นตัวเลือกที่นักพัฒนาจำนวนมากชื่นชอบ ภาษา Go ก็ให้ความเสถียรที่ดีกว่า ด้วย standard library ที่กว้างและคำมั่นเรื่องความเข้ากันได้ ทำให้โปรแกรมที่มีอายุมากกว่า 10 ปียังรันได้
กรณีที่ซอฟต์แวร์ทำงานได้ดีโดยไม่ต้องอัปเดต มักหมายความว่ามันถูกสร้างมาอย่างถูกต้องตั้งแต่แรก ซอฟต์แวร์ที่ใช้ส่วนตัวค่อนข้างง่ายกว่าเพราะความชอบไม่ได้เปลี่ยนมากนัก แต่เมื่อเขียนซอฟต์แวร์ให้คนอื่นใช้ ความต้องการอาจแตกต่างและอาจเกิดปัญหาที่ไม่คาดคิดได้ ตัวอย่างเช่น อาจล่มเมื่อจัดการไฟล์ขนาดใหญ่ และการแก้ไขอาจต้องเขียนซอฟต์แวร์ใหม่ไปครึ่งหนึ่ง นี่คือข้อโต้แย้งสำคัญที่สุดต่อแนวคิดที่ว่าซอฟต์แวร์ที่ไม่ค่อยเปลี่ยนแปลงย่อมดีกว่าเสมอ
Python เป็นตัวอย่างที่ไม่ดีเพราะมีการเปลี่ยนแปลงแบบทำลายความเข้ากันได้อยู่เรื่อย ๆ ขณะที่ Go หรือ Java นั้น โค้ดอายุ 10 ปีก็ยังทำงานได้ดีกับเครื่องมือสมัยใหม่ ส่วน Perl เป็นตัวอย่างที่ดียิ่งกว่า เพราะโค้ดอายุ 30 ปีก็ยังทำงานได้อยู่
กำลังทำงานกับ IBM mainframe (z/OS) อยู่ IBM ทำได้ดีที่สุดในแง่การรักษา backward compatibility Microsoft (Windows) มาเป็นอันดับสอง และ Linux (kernel) ABI เป็นอันดับสาม ระบบอื่น ๆ ส่วนใหญ่เจอปัญหาที่พบได้บ่อยใน OSS ซึ่งไม่ค่อยอยากเสียเวลากับการรักษาความเข้ากันได้
dependency อาจทำให้แอปกลายเป็น "เลือดอุ่น" ได้ แต่ Docker หรือการทำเป็น container ก็ช่วยบรรเทาปัญหานี้ได้ในระดับหนึ่ง เวลาเลือกไลบรารีมาใช้ในโปรเจกต์ ก็จะศึกษามากพอว่ามันเป็นไลบรารีแบบ "เลือดเย็น" หรือไม่ก่อนตัดสินใจ
วิศวกรจำนวนมากเวลาไปหาไลบรารีบน GitHub มักดูเวลาของ commit ล่าสุด และคิดว่ายิ่ง commit ล่าสุดมากก็ยิ่งได้รับการดูแลดีกว่า แต่การเจอโปรเจกต์ที่ถูก archive แล้ว ทว่ามีความเสถียรยาวนานและไม่มีบั๊ก ก็เหมือนการเจออัญมณีที่ซ่อนอยู่ในร้านของมือสอง
กำลังดูแล side project ของตัวเองอยู่ เริ่มมาตั้งแต่ 12-13 ปีก่อน และเคย rewrite ด้วย PHP, Laravel, Symfony ซึ่งมีคุณค่ามากในการเรียนรู้วิธีดูแลโปรเจกต์ระยะยาว ตัวอย่างเช่น มองหาโอกาสเปลี่ยนจาก Vagrant ไป Docker และลดความซับซ้อนจาก Vue + Axios + Webpack ไปเป็น Htmx ไม่นานมานี้ก็อัปเกรดเป็น PHP 8.2 และ Symfony 7 พร้อมผสานฟีเจอร์ที่อิงกับ ChatGPT เข้าไป
ช่วงไม่กี่ปีที่ผ่านมาเริ่มเอือมกับ mobile app ที่ต้องคอยแพตช์กันทุกไม่กี่ชั่วโมง ผู้เขียนอธิบาย static site generator ของตัวเองว่าเป็นแบบ "เลือดเย็น" ซึ่งรันบน Python 2 แต่ตอนนี้การติดตั้ง Python 2 ก็ยากขึ้นเรื่อย ๆ
SDK ที่เขียนในปี 1994-95 ถูกใช้งานต่อเนื่องจนกระทั่งออกจากบริษัทในปี 2017 มันเขียนด้วย ANSI C และสิ่งที่เขียนด้วย PHP (5) ก็ยังทำงานได้ดีบน PHP 8.2 เช่นกัน แต่ของพวกนี้ค่อนข้างน่าเบื่อและไม่ค่อยมีความหวือหวาให้พูดถึง
นอกเหนือจากที่บทความพูดถึงแล้ว การมี threat model ที่ปลอดภัยโดยธรรมชาติก็สำคัญเช่นกัน ตัวอย่างเช่น เว็บไซต์เต็มรูปแบบต้องรับมือกับผู้โจมตี, สแปมบอต ฯลฯ อยู่ตลอด จึงมีความเป็น "เลือดอุ่น" โดยธรรมชาติ ในทางกลับกัน static page อย่าง Tiddlywiki ดีกว่ามาก เพราะไม่จำเป็นต้องเอาขึ้นเว็บ และเบราว์เซอร์ก็เป็นแพลตฟอร์มที่เสถียรมาก