บทความนี้จะแชร์ข้อมูลเชิงลึกเกี่ยวกับวิธีเลือกไลบรารีหรือเฟรมเวิร์กที่จะใช้ภายในเว็บแอปพลิเคชัน การพูดคุยในที่นี้จะช่วยให้คุณชั่งน้ำหนักข้อดีและข้อเสียในการค้นหาไลบรารีหรือเฟรมเวิร์ก JavaScript ที่เหมาะกับปัญหาทางธุรกิจที่คุณพยายามแก้ไข การทำความเข้าใจข้อดีและข้อเสียที่ใช้ในสถานการณ์ต่างๆ เป็นกุญแจสำคัญในการตรวจสอบตัวเลือกไลบรารี JavaScript จำนวนมากที่มีอยู่
ไลบรารีและเฟรมเวิร์ก JavaScript คืออะไร
ไลบรารี JavaScript คืออะไร รูปแบบที่ง่ายที่สุดคือไลบรารี JavaScript เป็นโค้ดที่เขียนไว้ล่วงหน้าซึ่งคุณสามารถเรียกใช้ในโค้ดของโปรเจ็กต์เพื่อทำงานที่เฉพาะเจาะจงให้สำเร็จได้
โพสต์นี้พูดถึง "ห้องสมุด" เป็นหลัก อย่างไรก็ตาม การสนทนาหลายๆ เรื่องก็ใช้กับเฟรมเวิร์กได้เช่นกัน โดยสรุปแล้ว ความแตกต่างระหว่างทั้ง 2 อย่างมีดังนี้
- สำหรับไลบรารี โค้ดของแอปพลิเคชันจะเรียกใช้โค้ดไลบรารี
- สำหรับเฟรมเวิร์ก เฟรมเวิร์กจะเรียกใช้โค้ดของแอปพลิเคชัน
ตัวอย่างที่นำไปใช้ได้จริงต่อไปนี้จะช่วยอธิบายความแตกต่าง
ตัวอย่างการเรียกใช้ไลบรารี JavaScript
ไลบรารี JavaScript จะทำงานบางอย่างแล้วส่งคืนการควบคุมไปยังแอปพลิเคชันของคุณ เมื่อใช้ไลบรารี คุณจะควบคุมขั้นตอนของแอปพลิเคชันและเลือกเวลาที่จะเรียกใช้ไลบรารีได้
ในตัวอย่างต่อไปนี้ โค้ดของแอปพลิเคชันจะนำเข้าเมธอดจากไลบรารี lodash หลังจากฟังก์ชันเสร็จสมบูรณ์ ระบบจะส่งคืนการควบคุมไปยังแอปพลิเคชันของคุณ
import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello
เมื่อเรียกใช้เมธอด lodash.capitalize เมธอดจะเรียกใช้โค้ด JavaScript ที่เขียนไว้ล่วงหน้าซึ่งจะเปลี่ยนอักขระตัวแรกของสตริงให้เป็นตัวพิมพ์ใหญ่
ตัวอย่างการใช้เฟรมเวิร์ก JavaScript
เฟรมเวิร์ก JavaScript คือเทมเพลตโค้ดที่กำหนดไว้ล่วงหน้าซึ่งคุณใช้สร้างลักษณะการทำงานของแอปพลิเคชัน กล่าวคือ เมื่อคุณใช้เฟรมเวิร์ก เฟรมเวิร์กจะควบคุมขั้นตอนการทำงานของแอปพลิเคชัน หากต้องการใช้เฟรมเวิร์ก คุณต้องเขียนโค้ดของแอปพลิเคชันที่กำหนดเอง จากนั้นเฟรมเวิร์กจะเรียกใช้โค้ดของแอปพลิเคชัน
ตัวอย่างต่อไปนี้แสดงข้อมูลโค้ดที่ใช้เฟรมเวิร์ก JavaScript ของ Preact
import { createElement } from 'preact';
export default function App() {
return (
<p class="big">Hello World!</p>
)
}
ในตัวอย่างนี้ โปรดสังเกตว่าเฟรมเวิร์กมีสิทธิ์ควบคุมโค้ดที่คุณเขียนมากกว่า และในบางกรณี เฟรมเวิร์กยังควบคุมเวลาที่จะเรียกใช้โค้ดด้วย
เหตุผลที่ควรใช้ไลบรารี
การใช้ไลบรารี JavaScript จะช่วยหลีกเลี่ยงการเขียนโค้ดซ้ำโดยไม่จำเป็น ไลบรารีสามารถแยกตรรกะที่ซับซ้อน เช่น การจัดการวันที่หรือการคำนวณทางการเงิน นอกจากนี้ ไลบรารียังช่วยให้คุณเปิดตัวผลิตภัณฑ์เริ่มต้นได้เร็วขึ้น แทนที่จะต้องเขียนโค้ดทั้งหมดตั้งแต่ต้น ซึ่งอาจใช้เวลานาน
ไลบรารี JavaScript ฝั่งไคลเอ็นต์บางรายการช่วยแยกความผิดปกติของแพลตฟอร์มเว็บออกไป นอกจากนี้ คลังยังทำหน้าที่เป็นเครื่องมือการเรียนรู้ได้ด้วย ตัวอย่างเช่น หากคุณไม่คุ้นเคยกับฟังก์ชันการค่อยๆ เปลี่ยนของภาพเคลื่อนไหว ซอร์สโค้ดของไลบรารีจะช่วยให้คุณทราบวิธีการทำงานของการค่อยๆ เปลี่ยนดังกล่าว
ไลบรารีบางรายการได้รับการสนับสนุนจากบริษัทขนาดใหญ่ที่ลงทุนทั้งเวลาและเงินเพื่ออัปเดตไลบรารีให้เป็นปัจจุบันและปลอดภัยอยู่เสมอ ไลบรารีจำนวนมากมาพร้อมกับเอกสารประกอบที่ครอบคลุม ซึ่งช่วยให้คุณและทีมทำความคุ้นเคยกับการใช้งานไลบรารีได้อย่างรวดเร็ว
สรุปแล้ว การใช้ไลบรารี JavaScript จะช่วยประหยัดเวลาได้
เหตุใดคุณจึงควรสนใจการใช้งานไลบรารี
ในทางเทคนิค คุณสามารถพัฒนาเว็บแอปพลิเคชันตั้งแต่ต้น แต่ทำไมต้องลำบากในเมื่อคุณสามารถใช้ซอฟต์แวร์ฟรี (โอเพนซอร์ส) หรือซื้อโซลูชันที่ช่วยประหยัดเวลาและเงินในระยะยาวได้ มีไลบรารีและเฟรมเวิร์ก JavaScript จำนวนมากให้เลือกใช้ โดยแต่ละรายการมีแนวทางเฉพาะในการแก้ปัญหาและมีลักษณะที่แตกต่างกัน เช่น
- ไลบรารีสามารถเขียนและดูแลรักษาภายในได้ แทนที่จะเป็นบุคคลที่สาม
- ไลบรารีอาจมีใบอนุญาตทางกฎหมายที่เฉพาะเจาะจงซึ่งทำให้เหมาะหรือไม่เหมาะกับเว็บแอปพลิเคชันของคุณ
- ไลบรารีอาจล้าสมัยหรือไม่ได้รับการดูแลรักษา
- ไลบรารีช่วยลดความซับซ้อนของชุดงานที่ซับซ้อน และช่วยประหยัดเวลาและเงินได้มาก
- ไลบรารีสามารถใช้กันอย่างแพร่หลายในชุมชน และเป็นที่รู้จักกันดีในหมู่นักพัฒนาซอฟต์แวร์
คุณอาจคาดเดาได้ว่าลักษณะที่แตกต่างกันอาจส่งผลต่อเว็บแอปพลิเคชันในลักษณะที่แตกต่างกัน บางครั้งการตัดสินใจก็ไม่ได้ซับซ้อนขนาดนั้น และคุณสามารถเปลี่ยนไลบรารีได้อย่างปลอดภัยหากไม่ชอบ อย่างไรก็ตาม บางครั้งไลบรารีอาจส่งผลกระทบอย่างมากต่องานและเว็บแอปพลิเคชันของคุณ ซึ่งบ่งชี้ว่าอาจจำเป็นต้องใช้แนวทางที่มีข้อมูลมากขึ้น
มีสภาพแวดล้อม JavaScript ที่ไม่ใช่ฝั่งไคลเอ็นต์บางอย่าง เช่น บนเซิร์ฟเวอร์ (ทำงานในสภาพแวดล้อมระบบคลาวด์) หรือบน Raspberry Pi ซึ่งคุณอาจต้องปรับเกณฑ์ที่ใช้ในการตรวจสอบไลบรารีและเฟรมเวิร์ก
ประสิทธิภาพ
ไม่ควรละเลยผลกระทบด้านประสิทธิภาพของไลบรารี JavaScript ในเว็บแอปพลิเคชันฝั่งไคลเอ็นต์ ไลบรารี JavaScript ขนาดใหญ่อาจรบกวนประสิทธิภาพการโหลดหน้าเว็บ โปรดทราบว่าเวลาเพียงไม่กี่มิลลิวินาทีก็สร้างรายได้หลายล้าน
ลองพิจารณาสถานการณ์ที่คุณใช้ไลบรารี JavaScript สำหรับภาพเคลื่อนไหว ไลบรารีบางรายการอาจเพิ่มขนาดได้หลายสิบกิโลไบต์ และในบางกรณีอาจเพิ่มได้ถึงหลายร้อยกิโลไบต์ ทรัพยากร JavaScript เช่นนี้อาจทำให้การโหลดหน้าเว็บล่าช้าอย่างมาก เนื่องจากเบราว์เซอร์ต้องดาวน์โหลด แยกวิเคราะห์ คอมไพล์ และเรียกใช้โค้ด
ยิ่งไลบรารี JavaScript มีขนาดใหญ่ ผลกระทบด้านประสิทธิภาพต่อผู้ใช้ก็จะยิ่งมากขึ้น
เมื่อประเมินหรือใช้ไลบรารีหรือเฟรมเวิร์ก JavaScript ให้พิจารณาคำแนะนำต่อไปนี้เพื่อปรับปรุงประสิทธิภาพ
- หากมีไลบรารี JavaScript ขนาดใหญ่ ให้ลองใช้ไลบรารีอื่นที่มีขนาดเล็กลง ตัวอย่างเช่น date-fns มีฟังก์ชันการทำงานมากมายในขนาดที่สมเหตุสมผลกว่าตัวเลือกอื่นๆ
- ต่อจากตัวอย่าง date-fns ก่อนหน้า ให้นำเข้าเฉพาะฟังก์ชันที่ต้องการ เช่น
import { format } from 'date-fns'อย่าลืมใช้วิธีนี้ร่วมกับ Tree Shaking เพื่อให้มีการสร้างและส่งเพย์โหลด JavaScript ขั้นต่ำไปยังผู้ใช้ - ใช้เครื่องมือทดสอบประสิทธิภาพ เช่น Lighthouse เพื่อสังเกตผลกระทบด้านประสิทธิภาพของการใช้ไลบรารี JavaScript บางรายการ หากไลบรารีเพิ่มเวลาในการโหลดหน้าเว็บ 1 วินาที (อย่าลืมจำกัดเครือข่ายและ CPU ในระหว่างการทดสอบ) คุณอาจต้องประเมินไลบรารีที่เลือกอีกครั้ง นอกจากการตรวจสอบการโหลดหน้าเว็บแล้ว อย่าลืมสร้างโปรไฟล์พฤติกรรมของหน้าเว็บที่เรียกใช้โค้ดจากไลบรารีที่เป็นปัญหา เนื่องจากประสิทธิภาพการโหลดหน้าเว็บไม่ได้บอกข้อมูลทั้งหมด
- หากผู้เขียนไลบรารียินดีรับความคิดเห็น ให้ส่งข้อสังเกตเกี่ยวกับประสิทธิภาพ คำแนะนำ และแม้แต่การมีส่วนร่วมในโปรเจ็กต์ นี่คือจุดที่ชุมชนโอเพนซอร์สจะโดดเด่น หากตัดสินใจที่จะบริจาค คุณอาจต้องตรวจสอบกับนายจ้างก่อน
- ใช้เครื่องมือติดตามแพ็กเกจแบบอัตโนมัติ เช่น bundlesize เพื่อคอยดูการอัปเดตขนาดใหญ่ที่ไม่คาดคิดในไลบรารี เป็นเรื่องปกติที่ไลบรารี JavaScript จะมีขนาดใหญ่ขึ้นเมื่อเวลาผ่านไป การเพิ่มฟีเจอร์ การแก้ไขข้อบกพร่อง กรณีที่เกิดขึ้นไม่บ่อย และอื่นๆ ทั้งหมดนี้อาจเพิ่มขนาดไฟล์ของไลบรารีได้ เมื่อคุณ/ทีมของคุณตกลงที่จะใช้ไลบรารีแล้ว การอัปเดตไลบรารีอาจเป็นปัญหาที่น้อยลงและอาจทำให้เกิดคำถามเพียงเล็กน้อยหรือไม่มีเลย ในกรณีนี้ การใช้ระบบอัตโนมัติจะมีประโยชน์มาก
- ดูข้อกำหนดสำหรับไลบรารีและประเมินว่าแพลตฟอร์มเว็บมีฟังก์ชันการทำงานเดียวกันในตัวหรือไม่ ตัวอย่างเช่น แพลตฟอร์มเว็บมีตัวเลือกสีอยู่แล้ว ซึ่งทำให้ไม่จำเป็นต้องใช้ไลบรารี JavaScript ของบุคคลที่สามเพื่อใช้ฟังก์ชันการทำงานเดียวกัน
ความปลอดภัย
การใช้โมดูลของบุคคลที่สามมีความเสี่ยงด้านความปลอดภัยอยู่บ้าง แพ็กเกจที่เป็นอันตรายภายในฐานของโค้ดของเว็บแอปพลิเคชันอาจบั่นทอนความปลอดภัยของทั้งทีมนักพัฒนาซอฟต์แวร์และผู้ใช้
พิจารณาไลบรารีที่เผยแพร่ไปยังระบบนิเวศ NPM แพ็กเกจดังกล่าวอาจถูกต้องตามกฎหมาย อย่างไรก็ตาม แพ็กเกจอาจถูกบุกรุกเมื่อเวลาผ่านไป
เคล็ดลับด้านความปลอดภัยที่ควรพิจารณาเมื่อใช้หรือประเมินโค้ดของบุคคลที่สามมีดังนี้
- หากใช้ GitHub ให้พิจารณาข้อเสนอด้านความปลอดภัยของโค้ด เช่น Dependabot หรือพิจารณาใช้บริการอื่นๆ ที่สแกนหาช่องโหว่ในโค้ด เช่น snyk.io
- ลองใช้บริการตรวจสอบโค้ด ซึ่งเป็นทีมวิศวกรที่สามารถตรวจสอบโค้ดของบุคคลที่สามที่คุณใช้อยู่ด้วยตนเอง
- ประเมินว่าคุณควรล็อกทรัพยากร Dependency ไว้กับเวอร์ชันที่เฉพาะเจาะจง หรือคอมมิตโค้ดของบุคคลที่สามภายในระบบควบคุมเวอร์ชัน วิธีนี้จะช่วยล็อกทรัพยากร Dependency ไว้ที่เวอร์ชันใดเวอร์ชันหนึ่ง ซึ่งน่าจะถือว่าปลอดภัย ซึ่งอาจส่งผลเสียต่อความปลอดภัย เนื่องจากคุณอาจพลาดการอัปเดตที่สำคัญของไลบรารี
- สแกนหน้าแรกของโปรเจ็กต์หรือหน้า GitHub (หากมี) ตรวจสอบว่ามีปัญหาด้านความปลอดภัยที่ยังไม่ได้รับการแก้ไขหรือไม่ และปัญหาด้านความปลอดภัยก่อนหน้านี้ได้รับการแก้ไขภายในกรอบเวลาที่เหมาะสมหรือไม่
- โค้ดของบุคคลที่สามที่ใช้โค้ดของบุคคลที่สามอื่นๆ อาจมีความเสี่ยงมากกว่าไลบรารีที่ไม่มีทรัพยากร Dependency โปรดคำนึงถึงความเสี่ยงนี้
การช่วยเหลือพิเศษ
คุณอาจสงสัยว่าไลบรารีซอฟต์แวร์เกี่ยวข้องกับการช่วยเหลือพิเศษบนเว็บอย่างไร แม้ว่าจะใช้ไลบรารีซอฟต์แวร์ในสภาพแวดล้อมต่างๆ ได้ แต่ในบริบทของไลบรารีที่ใช้ JavaScript ฝั่งไคลเอ็นต์ การช่วยเหลือพิเศษบนเว็บมีความสำคัญอย่างยิ่ง
ไลบรารีที่ใช้ JavaScript ฝั่งไคลเอ็นต์ (หรือเฟรมเวิร์ก) สามารถเพิ่มหรือลดการช่วยเหลือพิเศษของเว็บไซต์ได้ ลองพิจารณาไลบรารี JavaScript ของบุคคลที่สามที่เพิ่มแถบเลื่อนรูปภาพลงในหน้าเว็บ หากแถบเลื่อนรูปภาพไม่คำนึงถึงการช่วยเหลือพิเศษบนเว็บ คุณในฐานะนักพัฒนาเว็บอาจมองข้ามฟีเจอร์ที่สำคัญดังกล่าว และเปิดตัวผลิตภัณฑ์ที่ไม่มีฟีเจอร์สำคัญ เช่น แถบเลื่อนที่ไปยังส่วนต่างๆ ได้ด้วยแป้นพิมพ์
- ปลั๊กอินการจัดพิมพ์ที่ปรับเปลี่ยนตามอุปกรณ์รองรับผู้ใช้ที่ซูมเข้าหรือออกจากหน้าเว็บหรือไม่
- ปลั๊กอินเครื่องมืออัปโหลดไฟล์รองรับการอัปโหลดไฟล์จากอุปกรณ์ช่วยเหลือพิเศษไหม
- ไลบรารีภาพเคลื่อนไหวมีการรองรับผู้ใช้ที่ต้องการลดการเคลื่อนไหวไหม
- ปลั๊กอินแผนที่แบบอินเทอร์แอกทีฟรองรับการใช้งานเฉพาะแป้นพิมพ์หรือไม่
- ไลบรารีโปรแกรมเล่นเสียงมอบประสบการณ์ที่เหมาะสมในโปรแกรมอ่านหน้าจอหรือไม่
คุณซึ่งเป็นนักพัฒนาเว็บควรคาดหวังว่าคุณจะต้องมีส่วนร่วมในระดับหนึ่งเพื่อให้เป็นไปตามข้อกำหนดด้านการช่วยเหลือพิเศษดังกล่าว เช่น
- สำหรับฟีเจอร์ที่ขาดหายไป คุณสามารถใช้ฟีเจอร์ดังกล่าวภายในฐานของโค้ดได้ แม้ว่าจะยังคงใช้ไลบรารีที่เป็นปัญหาอยู่ก็ตาม
- ด้วยการสนับสนุนจากนายจ้าง คุณสามารถเพิ่มฟีเจอร์ที่ขาดหายไปดังกล่าวลงในไลบรารีได้ หากผู้เขียนไลบรารีอนุญาตให้มีส่วนร่วมดังกล่าว
- คุณสามารถเปิดการสนทนากับผู้เขียนไลบรารีได้ เช่น ฟีเจอร์การช่วยเหลือพิเศษที่เฉพาะเจาะจงเหล่านี้อยู่ในแผนกลยุทธ์ของคุณหรือไม่ คุณเห็นด้วยไหมว่าควรเก็บหนังสือเหล่านี้ไว้ในห้องสมุด
- สำหรับ Use Case ยอดนิยม คุณสามารถสำรวจตัวเลือกไลบรารีอื่นๆ ที่เข้าถึงได้ง่ายกว่า ซึ่งอาจมีอยู่แต่ค้นหาได้ยากกว่า
- ในกรณีที่รุนแรง คุณอาจต้องทิ้งไลบรารีทั้งหมดและใช้ฟีเจอร์ตั้งแต่ต้น กรณีนี้อาจเกิดขึ้นเมื่อไลบรารีหรือเฟรมเวิร์กมีประสบการณ์การช่วยเหลือพิเศษที่ลดลงเมื่อใช้งานครั้งแรก และคุณต้องเลิกทำสิ่งที่ไลบรารีหรือเฟรมเวิร์กควรจะให้คุณฟรีๆ เป็นจำนวนมาก
การประชุม
ไลบรารีซอฟต์แวร์ที่ใช้รูปแบบการเขียนโค้ดที่กำหนดไว้จะทำงานได้ง่ายกว่า หากไลบรารีใช้รูปแบบการเขียนโค้ดที่ไม่เคยได้ยินมาก่อน คุณและทีมอาจทำงานกับไลบรารีดังกล่าวได้ยาก
หากไลบรารีไม่เป็นไปตามรูปแบบการเขียนโค้ดทั่วไป (เช่น คู่มือแนะนำสไตล์ทั่วไป) คุณจะแก้ไขปัญหาได้ไม่มากนักในทันที อย่างไรก็ตาม คุณยังมีตัวเลือกต่อไปนี้
- โปรดแยกความแตกต่างระหว่างซอร์สโค้ดของไลบรารีกับ API ที่แสดงต่อคุณซึ่งเป็นผู้ใช้ไลบรารี แม้ว่าซอร์สโค้ดภายในอาจใช้รูปแบบที่ไม่คุ้นเคย แต่หาก API (ส่วนของไลบรารีที่คุณโต้ตอบด้วย) ใช้รูปแบบที่คุ้นเคย ก็อาจไม่มีอะไรน่ากังวล
- หาก API ของไลบรารีไม่เป็นไปตามรูปแบบการเขียนโค้ดทั่วไป คุณสามารถใช้รูปแบบการออกแบบ JavaScript เช่น รูปแบบพร็อกซี เพื่อรวมและเก็บการโต้ตอบทั้งหมดกับไลบรารีไว้ในไฟล์เดียวในฐานของโค้ด จากนั้นพร็อกซีจะเสนอ API ที่ใช้งานง่ายขึ้นให้กับส่วนอื่นๆ ของโค้ดภายในฐานของโค้ดได้
แบบแผนมีบทบาทสำคัญต่อความสะดวกในการใช้งาน ไลบรารีที่มี API ที่ใช้งานง่ายจะช่วยประหยัดเวลาได้หลายชั่วโมงหรือหลายวันเมื่อเทียบกับ API ที่ใช้งานยากซึ่งต้องทำการทดสอบหลายครั้งจึงจะเข้าใจ
อัปเดต
ตัวอย่างเช่น ไลบรารีที่ทำงานได้อย่างสมบูรณ์ซึ่งทำการคำนวณทางคณิตศาสตร์เพียงไม่กี่รายการอาจไม่จำเป็นต้องอัปเดตบ่อยนัก อันที่จริงแล้ว ไลบรารีที่มีฟีเจอร์ครบถ้วนนั้นหาได้ยากในโลกของการพัฒนาเว็บที่เปลี่ยนแปลงอยู่ตลอดเวลา อย่างไรก็ตาม อาจมีบางครั้งที่คุณต้องการให้ผู้เขียนไลบรารีตอบสนองและเต็มใจที่จะทำการอัปเดต การวิจัยและการค้นพบใหม่ๆ อาจเผยให้เห็นวิธีที่ดีกว่าในการทำสิ่งต่างๆ ดังนั้นเทคนิคที่ใช้ในไลบรารีและเฟรมเวิร์กจึงอาจมีการเปลี่ยนแปลงอยู่เสมอ
เมื่อเลือกไลบรารีหรือเฟรมเวิร์ก ให้พิจารณาวิธีจัดการการอัปเดต และโปรดทราบว่าการตัดสินใจดังกล่าวอาจส่งผลต่อคุณดังนี้
- ไลบรารีมีกำหนดการเผยแพร่ที่สมเหตุสมผลไหม ตัวอย่างเช่น การอัปเดตที่เก็บซอร์สโค้ดอาจเกิดขึ้นบ่อยครั้ง แต่หากการอัปเดตดังกล่าวไม่ได้ "เผยแพร่" หรือ "เปิดตัว" ตามนั้น คุณจะพบว่าการดาวน์โหลดการอัปเดตดังกล่าวอาจเป็นเรื่องยาก
- ไลบรารีเผยแพร่การอัปเดตด้วยรูปแบบการกำหนดเวอร์ชันของซอฟต์แวร์ที่เหมาะสมหรือไม่ คลังควรช่วยประหยัดเวลา หากคุณต้องเปลี่ยนโค้ดโดยไม่คาดคิดทุกครั้งที่อัปเดตเวอร์ชันไลบรารี การดำเนินการนี้อาจขัดต่อวัตถุประสงค์ของการใช้ไลบรารีนั้นตั้งแต่แรก บางครั้งการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ในทางอุดมคติแล้ว การเปลี่ยนแปลงจะเกิดขึ้นไม่บ่อยนักและไม่ได้บังคับให้ผู้ใช้ไลบรารีต้องดำเนินการ
- ไลบรารีพยายามทำให้เข้ากันได้แบบย้อนหลังไหม บางครั้งการอัปเดตซอฟต์แวร์อาจมาพร้อมกับการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ แต่ก็ให้ความเข้ากันได้แบบย้อนหลังด้วย ซึ่งจะช่วยให้ผู้ใช้ไลบรารีใช้ไลบรารีเวอร์ชันล่าสุดได้โดยมีการเปลี่ยนแปลงโค้ดน้อยที่สุด
การอนุญาตให้ใช้สิทธิ
การอนุญาตให้ใช้สิทธิซอฟต์แวร์เป็นสิ่งสำคัญในการใช้ไลบรารีซอฟต์แวร์ของบุคคลที่สาม ผู้เขียนไลบรารีอาจกำหนดใบอนุญาตให้กับไลบรารีของตน หากคุณกำลังพิจารณาใช้ไลบรารี ตัวเลือกใบอนุญาตของไลบรารีอาจส่งผลต่อคุณ
ตัวอย่างเช่น ไลบรารี JavaScript อาจมีใบอนุญาตซอฟต์แวร์ที่อนุญาตให้คุณใช้ในสภาพแวดล้อมที่ไม่ใช่เชิงพาณิชย์ สำหรับโปรเจ็กต์งานอดิเรกส่วนตัว ตัวเลือกนี้อาจเป็นตัวเลือกที่ยอดเยี่ยม หากโปรเจ็กต์ของคุณมีองค์ประกอบเชิงพาณิชย์ คุณอาจต้องพิจารณาใบอนุญาตระดับองค์กร
หากมีข้อสงสัย โปรดขอคำแนะนำทางกฎหมายจากผู้เชี่ยวชาญหรือปรึกษาทีมกฎหมายภายในบริษัทของคุณ
ชุมชน
ไลบรารีหรือเฟรมเวิร์กที่มีชุมชนผู้ใช้/ผู้ร่วมให้ข้อมูลขนาดใหญ่อาจเป็นประโยชน์ แต่ก็ไม่ได้รับประกันว่าจะเป็นเช่นนั้นเสมอไป โดยทั่วไปแล้ว ยิ่งไลบรารีหรือเฟรมเวิร์กมีผู้ใช้มากเท่าใด ก็ยิ่งมีแนวโน้มที่จะได้รับประโยชน์มากขึ้นเท่านั้น พิจารณาข้อดีและข้อเสียต่อไปนี้ของการเข้าร่วมชุมชนนักพัฒนาซอฟต์แวร์
ข้อดี
- ฐานผู้ใช้ขนาดใหญ่อาจหมายถึงโอกาสที่มากขึ้นในการตรวจพบบั๊กตั้งแต่เนิ่นๆ และบ่อยครั้ง
- ชุมชนขนาดใหญ่ที่มีการใช้งานอยู่เสมออาจหมายถึงมีบทแนะนำ คู่มือ วิดีโอ และแม้แต่หลักสูตรเกี่ยวกับไลบรารีหรือเฟรมเวิร์กที่เป็นปัญหามากขึ้น
- ชุมชนขนาดใหญ่ที่มีการใช้งานอยู่เสมออาจหมายถึงการสนับสนุนเพิ่มเติมในฟอรัมและเว็บไซต์คำถามและคำตอบ ซึ่งจะเพิ่มโอกาสที่คำถามเกี่ยวกับการสนับสนุนจะได้รับคำตอบ
- ชุมชนที่มีส่วนร่วมอาจหมายถึงผู้มีส่วนร่วมภายนอกที่มากขึ้นในคลังหรือเฟรมเวิร์ก ซึ่งจะช่วยส่งมอบฟีเจอร์ที่ไม่ได้อยู่ในแผนกลยุทธ์ของผู้เขียน
- เมื่อไลบรารีหรือเฟรมเวิร์กเป็นที่นิยมในชุมชน ก็มีแนวโน้มมากขึ้นที่เพื่อนร่วมงานและเพื่อนร่วมงานของคุณจะได้ยินหรือคุ้นเคยกับไลบรารีหรือเฟรมเวิร์กดังกล่าว
ข้อเสีย
- โปรเจ็กต์ที่มีฐานผู้ใช้ขนาดใหญ่และหลากหลายอาจมีขนาดใหญ่เกินไปจากการเพิ่มฟีเจอร์อย่างต่อเนื่อง ไลบรารีที่มากเกินไปอาจส่งผลเสียต่อประสิทธิภาพของเว็บ
- โปรเจ็กต์ที่มีชุมชนที่กระตือรือร้นและมีส่วนร่วมอาจสร้างความเครียดให้กับผู้เขียนและผู้ดูแล และอาจต้องมีการดูแลชุมชนอย่างเข้มงวด
- โปรเจ็กต์ที่เติบโตอย่างรวดเร็วแต่ไม่มีการสนับสนุนที่เหมาะสมอาจเริ่มแสดงสัญญาณของการมีชุมชนที่เป็นพิษ ตัวอย่างเช่น นักพัฒนาเว็บมือใหม่หรือระดับจูเนียร์อาจรู้สึกว่าไม่ได้รับการต้อนรับในชุมชนบางแห่งเนื่องจากการกีดกัน
เอกสารประกอบ
ไม่ว่าไลบรารีหรือเฟรมเวิร์ก JavaScript จะเรียบง่ายหรือซับซ้อนเพียงใด เอกสารประกอบซอฟต์แวร์ก็ช่วยได้เสมอ แม้แต่นักพัฒนาซอฟต์แวร์ที่มีประสบการณ์สูงก็ยังใช้เอกสารประกอบแทนที่จะคิดโค้ดขึ้นมาเอง เอกสารประกอบจะอธิบายถึง API ที่คุณควรใช้และวิธีใช้
เอกสารประกอบอาจมีโค้ดตัวอย่างด้วย ซึ่งจะช่วยให้คุณเริ่มต้นใช้งานได้อย่างรวดเร็วและง่ายดายยิ่งขึ้น เมื่อประเมินไลบรารีหรือเฟรมเวิร์ก คุณสามารถถามคำถามต่อไปนี้
- ไลบรารีมีเอกสารประกอบไหม หากไม่ คุณจะต้องสามารถแก้ปัญหาต่างๆ ได้ด้วยตนเอง
- เอกสารประกอบชัดเจน เข้าใจง่าย และไม่มีความกำกวมหรือไม่ นักพัฒนาแอปจำนวนมากใช้เวลาส่วนใหญ่ไปกับเอกสารประกอบ แม้ว่าอาจดูเป็นเรื่องเล็กน้อย แต่ความชัดเจนในเอกสารข้อความอาจส่งผลอย่างมากต่อประสิทธิภาพการทำงานของคุณ
- เอกสารประกอบสร้างขึ้นโดยอัตโนมัติทั้งหมดใช่ไหม เอกสารประกอบดังกล่าวอาจทำความเข้าใจได้ยากกว่า และไม่ได้ให้คำแนะนำที่ชัดเจนเกี่ยวกับวิธีใช้ API เสมอไป
- เอกสารเป็นข้อมูลล่าสุดหรือไม่ บางครั้งการดูแลรักษาเอกสารประกอบก็ถูกมองว่าเป็นเรื่องรอง หากมีการอัปเดตไลบรารีแต่ไม่มีการอัปเดตเอกสารประกอบ อาจทำให้เสียเวลาในการพัฒนา
- เอกสารประกอบมีความครอบคลุมและมีให้บริการในหลายรูปแบบหรือไม่ คู่มือผู้ใช้ โค้ดตัวอย่าง เอกสารอ้างอิง การสาธิตแบบสด และบทแนะนำล้วนเป็นรูปแบบเอกสารที่มีคุณค่าซึ่งจะช่วยให้คุณใช้ไลบรารีหรือเฟรมเวิร์กได้สำเร็จ
เอกสารอาจไม่สมบูรณ์เสมอไป ซึ่งก็ไม่เป็นไร คุณจะต้องประเมินความต้องการขององค์กร ข้อกำหนดของโปรเจ็กต์ และความซับซ้อนของซอฟต์แวร์ แล้วใช้ข้อมูลดังกล่าวเพื่อกำหนดระดับของเอกสารประกอบที่ต้องการ
บทสรุป
การรู้สึกสับสนเมื่อเลือกไลบรารีหรือเฟรมเวิร์กเป็นครั้งแรกเป็นเรื่องปกติ เช่นเดียวกับสิ่งอื่นๆ ยิ่งคุณเรียนรู้และฝึกฝนงานมากเท่าไร คุณก็จะยิ่งเก่งขึ้นเท่านั้น โพสต์นี้อาจเป็นประโยชน์เมื่อคุณเลือกไลบรารีหรือเฟรมเวิร์กที่จะใช้ในครั้งถัดไป คุณสามารถใช้หัวข้อในโพสต์นี้เป็นรายการตรวจสอบได้ เช่น ไลบรารีนี้มีประสิทธิภาพไหม ไลบรารีนี้เป็นไปตามมาตรฐานธุรกิจของฉันสำหรับการช่วยเหลือพิเศษบนเว็บหรือไม่
ยังมีแง่มุมอื่นๆ ของไลบรารีและเฟรมเวิร์กที่คุณอาจต้องพิจารณา และยังไม่ได้กล่าวถึงมากนักในโพสต์นี้ ได้แก่
- ความสามารถในการขยาย: การขยายไลบรารีด้วยตรรกะและ/หรือลักษณะการทำงานที่กำหนดเองทำได้ง่ายเพียงใด
- เครื่องมือ: หากมี ไลบรารีมีเครื่องมือต่างๆ เช่น ปลั๊กอินตัวแก้ไขโค้ด เครื่องมือแก้ไขข้อบกพร่อง และปลั๊กอินระบบบิลด์หรือไม่
- สถาปัตยกรรม: โค้ดที่สะอาดเป็นสิ่งสำคัญ แต่สถาปัตยกรรมโดยรวมของไลบรารีสมเหตุสมผลหรือไม่
- การทดสอบ: โปรเจ็กต์มีชุดโปรแกรมทดสอบไหม เว็บไซต์ของโปรเจ็กต์ใช้ป้ายหรือตัวบ่งชี้ที่ชุดโปรแกรมทดสอบผ่านการคอมมิตล่าสุดหรือไม่
- ความเข้ากันได้: ไลบรารีทำงานร่วมกับไลบรารีและ/หรือเฟรมเวิร์กอื่นๆ ที่คุณใช้อยู่ได้ดีหรือไม่
- ต้นทุน: ต้นทุนของเฟรมเวิร์กคือเท่าใด เป็นโอเพนซอร์สหรือพร้อมจำหน่ายไหม
- เมตริกที่ไม่มีความหมาย: เมตริกนี้ควรอยู่ในอันดับต่ำในรายการเกณฑ์ หรืออาจละเว้นไปเลยก็ได้ แต่คุณอาจต้องพิจารณา "การโหวต" ของโปรเจ็กต์ บัญชีโซเชียลมีเดียที่แสดงถึงโปรเจ็กต์ และ/หรือจำนวนข้อบกพร่อง/ปัญหาที่เปิดอยู่ในหน้าโปรเจ็กต์