ชุมชนนักพัฒนาซอฟต์แวร์กำลังตั้งคำถามกับความเชื่อดั้งเดิมที่ว่าการพึ่งพาไลบรารีภายนอกจะดีกว่าการสร้างโซลูชันภายในองค์กรเสมอ นักพัฒนาจำนวนมากขึ้นเริ่มต่อต้านความเชื่อที่มองว่า Not Invented Here (NIH) syndrome เป็นสิ่งไม่ดี โดยให้เหตุผลว่าการเขียนโค้ดแบบกำหนดเองมักจะคุ้มค่ากว่าการใช้ไลบรารีจากบุคคลที่สาม
ต้นทุนที่ซ่อนเร้นของการพึ่งพาไลบรารีภายนอก
แม้ว่าไลบรารีภายนอกจะสัญญาว่าให้ฟังก์ชันการทำงานฟรี แต่นักพัฒนากำลังค้นพบว่าสิ่งเหล่านี้มาพร้อมกับค่าใช้จ่ายที่ซ่อนเร้นอย่างมีนัยสำคัญ การเรียนรู้ไลบรารีที่ซับซ้อนมักใช้เวลานานกว่าการเขียนโซลูชันแบบกำหนดเองที่เรียบง่าย การเปลี่ยนแปลงที่ทำลายความเข้ากันได้ในไลบรารีสามารถกระตุ้นให้เกิดการเขียนโค้ดใหม่ที่มีค่าใช้จ่ายสูง การปรับใช้งานกลายเป็นเรื่องซับซ้อนเมื่อต้องรวมและแจกจ่ายไลบรารีหลายตัวไปยังเครื่องไคลเอนต์
ความซับซ้อนเพิ่มขึ้นเป็นทวีคูณเมื่อมีการนำ containerization และระบบ bundling มาใช้เพียงเพื่อจัดการ dependency chains ทีมพัฒนาหลายทีมพบว่าตนเองใช้เวลาในการจัดการโครงสร้างพื้นฐานการปรับใช้งานมากกว่าการสร้างฟีเจอร์หลักของแอปพลิเคชัน
ปัจจัยเสี่ยงจากการพึ่งพิง
การพึ่งพิงเชิงพาณิชย์:
- แรงจูงใจในการผูกมัดกับผู้ขาย
- แหล่งสนับสนุนเดียว
- ความเสี่ยงด้านความต่อเนื่องของธุรกิจ
- ต้นทุนระยะยาวที่สูงขึ้น
ต้นทุนทั่วไปจากการพึ่งพิง:
- การลงทุนเวลาในการเรียนรู้
- การจัดการการเปลี่ยนแปลงที่ทำลายความเข้ากันได้
- ความซับซ้อนในการปรับใช้
- ความเสี่ยงด้านความปลอดภัยของห่วงโซ่อุปทาน
- ผลกระทบด้านประสิทธิภาพ
กรอบการทำงานสำหรับการตัดสินใจเลือกใช้ไลบรารีอย่างชาญฉลาด
การอภิปรายในชุมชนได้เน้นเกณฑ์สำคัญห้าประการสำหรับการประเมินไลบรารี ได้แก่ ความแพร่หลาย ความเสถียร ความลึก การใช้งาน และความแน่นหนา ความแพร่หลายหมายถึงว่าไลบรารีมีให้ใช้งานอย่างกว้างขวางเพียงใดในสภาพแวดล้อมเป้าหมาย ความเสถียรวัดความถี่ของการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ ความลึกพิจารณาว่าฟังก์ชันการทำงานพื้นฐานจะยากแค่ไหนในการทำซ้ำ การใช้งานประเมินความสะดวกสบายของ API ความแน่นหนาตรวจสอบว่า abstraction รั่วไหลรายละเอียดการดำเนินการหรือไม่
เทคนิคหนึ่งสำหรับทำให้ซอฟต์แวร์แข็งแกร่งขึ้นคือการลดสิ่งที่ซอฟต์แวร์ของคุณพึ่งพา – ยิ่งมีสิ่งที่อาจผิดพลาดน้อยลง สิ่งที่จะผิดพลาดก็จะน้อยลง
นักพัฒนาสังเกตว่าผู้สนับสนุนการใช้ไลบรารีมักมุ่งเน้นเฉพาะการใช้งานเท่านั้น ขณะที่เพิกเฉยต่อปัจจัยสำคัญอื่นๆ
ตัวอย่างการประเมิน Dependencies ที่ดี
POSIX System Calls:
- การแพร่หลาย: มีให้ใช้งานบน Linux , Android , macOS , BSDs
- ความเสถียร: เสถียรมาก มีการเปลี่ยนแปลงที่ทำลายระบบได้น้อยมาก
- ความลึก: การเรียกใช้ครั้งเดียวซ่อนโค้ดของ kernel หลายแสนบรรทัด
- ความสะดวกในการใช้งาน: ปานกลาง (รูปแบบของ C , มี flags มาก)
- ความแน่นหนา: ส่วนใหญ่ดี มีข้อยกเว้นเล็กน้อยในอุปกรณ์จัดเก็บข้อมูล
Web Platform ( HTML , CSS , JS , Web APIs ):
- การแพร่หลาย: แพลตฟอร์มที่ใช้งานแพร่หลายที่สุดในโลก
- ความเสถียร: มีความมุ่งมั่นในการรักษาความเข้ากันได้แบบย้อนหลังอย่างแข็งแกร่ง
- ความลึก: การเขียน browser แบบกำหนดเองไม่สามารถทำได้
- ความสะดวกในการใช้งาน: เพียงพอ พร้อมเอกสารที่ยอดเยี่ยม
- ความแน่นหนา: ดี ยกเว้นการโต้ตอบกับไฟล์/เสียง/วิดีโอ
ไลบรารีเชิงพาณิชย์ถูกตรวจสอบอย่างใกล้ชิด
ไลบรารีแบบเสียเงินเผชิญกับความสงสัยเป็นพิเศษจากชุมชนนักพัฒนา โซลูชันเชิงพาณิชย์สร้างความเสี่ยงจากการติดอยู่กับผู้ขาย เนื่องจากบริษัทมีแรงจูงใจทางการเงินที่จะทำให้การเปลี่ยนแปลงมีต้นทุนสูง เมื่อผู้ขายล้มละลายหรือหยุดให้การสนับสนุน โครงการที่พึ่งพาโซลูชันของพวกเขาจะเผชิญกับความเสี่ยงด้านความต่อเนื่องอย่างจริงจัง ทางเลือก open source แม้จะไม่สมบูรณ์แบบ แต่โดยทั่วไปจะให้ความเสถียรระยะยาวและการสนับสนุนจากชุมชนมากกว่า
แนวทางการใช้ไลบรารีน้อยที่สำเร็จ
ตัวอย่างในโลกจริงแสดงให้เห็นถึงความเป็นไปได้ของกลยุทธ์การใช้ไลบรารีน้อย TigerBeetle ซึ่งเป็นฐานข้อมูลทางการเงิน ดำเนินการด้วยนโยบายไม่มีไลบรารีเลยนอกเหนือจาก core toolchain แนวทางนี้ช่วยขจัดความเสี่ยงจากการโจมตีห่วงโซ่อุปทาน ปรับปรุงประสิทธิภาพ และลดความซับซ้อนในการติดตั้ง
กลยุทธ์นี้ทำงานได้ดีเป็นพิเศษสำหรับโครงสร้างพื้นฐานรากฐาน ซึ่งต้นทุนไลบรารีขยายตัวไปทั่วทั้ง technology stack ทีมที่ใช้แนวทางนี้ลงทุนอย่างหนักในการเชี่ยวชาญ core tools ที่เลือกใช้แทนที่จะเรียนรู้ framework เฉพาะทางหลายตัว
การหาสมดุลที่เหมาะสม
การอภิปรายนี้ไม่ได้สนับสนุนให้หลีกเลี่ยงไลบรารีทั้งหมด มาตรฐานเช่น POSIX system calls, terminal control codes และ web platform APIs เป็นตัวแทนของไลบรารีที่ยอดเยี่ยมเนื่องจากความแพร่หลาย ความเสถียร และความลึก สิ่งเหล่านี้ให้ฟังก์ชันการทำงานมหาศาลที่จะไม่สามารถสร้างขึ้นใหม่ได้ในทางปฏิบัติ ขณะที่ยังคงความเข้ากันได้อย่างกว้างขวาง
สิ่งสำคัญอยู่ที่การประเมินอย่างมีวิจารณญาณ การตัดสินใจเลือกใช้ไลบรารีแต่ละครั้งควรชั่งน้ำหนักต้นทุนเทียบกับผลประโยชน์ โดยพิจารณาการบำรุงรักษาระยะยาว ความซับซ้อนของการปรับใช้งาน และความต้องการเฉพาะของโครงการ การจัดการไลบรารีอย่างชาญฉลาดหมายถึงการเลือกอย่างชาญฉลาดแทนที่จะเลือกใช้โซลูชันภายนอกโดยอัตโนมัติ