บทความนี้จะแชร์ข้อมูลเชิงลึกเกี่ยวกับวิธีเลือกไลบรารีหรือเฟรมเวิร์กที่จะใช้ในเว็บแอปพลิเคชัน การพูดคุยในบทนี้จะช่วยให้คุณชั่งน้ำหนักข้อดีและข้อเสียในการค้นหาไลบรารีหรือเฟรมเวิร์ก 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
- ลองใช้บริการตรวจสอบโค้ด ซึ่งเป็นทีมวิศวกรที่สามารถตรวจสอบโค้ดของบุคคลที่สามที่คุณใช้อยู่ด้วยตนเอง
- ประเมินว่าคุณควรล็อกการพึ่งพาไว้กับเวอร์ชันที่เจาะจง หรือคอมมิตโค้ดของบุคคลที่สามภายในการควบคุมเวอร์ชันหรือไม่ ซึ่งจะช่วยล็อกการพึ่งพาไว้กับเวอร์ชันหนึ่งๆ ที่ถือว่าปลอดภัย แต่การดำเนินการนี้อาจส่งผลเสียต่อความปลอดภัย เนื่องจากคุณอาจพลาดการอัปเดตที่สำคัญในคลัง
- สแกนหน้าแรกของโปรเจ็กต์หรือหน้า GitHub หากมี ตรวจสอบว่ามีปัญหาด้านความปลอดภัยที่ยังไม่ได้รับการแก้ไขหรือไม่ และปัญหาด้านความปลอดภัยก่อนหน้านี้ได้รับการแก้ไขภายในกรอบเวลาที่เหมาะสมหรือไม่
- โค้ดของบุคคลที่สามที่ใช้โค้ดของบุคคลที่สามอื่นๆ อาจเสี่ยงมากกว่าไลบรารีที่ไม่มีทรัพยากรภายนอก โปรดคำนึงถึงความเสี่ยงนี้
การช่วยเหลือพิเศษ
คุณอาจสงสัยว่าไลบรารีซอฟต์แวร์เกี่ยวข้องกับการช่วยเหลือพิเศษบนเว็บอย่างไร แม้ว่าไลบรารีซอฟต์แวร์จะใช้ได้ในสภาพแวดล้อมต่างๆ แต่การช่วยเหลือพิเศษบนเว็บก็มีความสำคัญอย่างยิ่งในบริบทของไลบรารีฝั่งไคลเอ็นต์ที่ใช้ JavaScript
ไลบรารี (หรือเฟรมเวิร์ก) ที่ใช้ JavaScript ฝั่งไคลเอ็นต์อาจเพิ่มหรือลดการช่วยเหลือพิเศษของเว็บไซต์ ลองใช้ไลบรารี JavaScript ของบุคคลที่สามที่เพิ่มแถบเลื่อนรูปภาพลงในหน้า หากแถบเลื่อนรูปภาพไม่ได้คำนึงถึงความพร้อมใช้งานบนเว็บ คุณในฐานะนักพัฒนาเว็บอาจมองข้ามฟีเจอร์สำคัญดังกล่าวและเปิดตัวผลิตภัณฑ์ที่ไม่มีฟีเจอร์สำคัญ เช่น แถบเลื่อนที่ไปยังส่วนต่างๆ ได้ด้วยแป้นพิมพ์
- ปลั๊กอินแบบอักษรที่ปรับเปลี่ยนตามพื้นที่ทำงานรองรับผู้ใช้ที่ซูมเข้าหรือออกหน้าเว็บหรือไม่
- ปลั๊กอินเครื่องมืออัปโหลดไฟล์รองรับการอัปโหลดไฟล์จากอุปกรณ์ช่วยเหลือพิเศษไหม
- คลังภาพเคลื่อนไหวรองรับผู้ใช้ที่ต้องการลดการเคลื่อนไหวไหม
- ปลั๊กอินแผนที่แบบอินเทอร์แอกทีฟรองรับการใช้งานด้วยแป้นพิมพ์เท่านั้นไหม
- คลังโปรแกรมเล่นเสียงมอบประสบการณ์การใช้งานที่เหมาะสมในโปรแกรมอ่านหน้าจอหรือไม่
เราคาดหวังว่าคุณในฐานะนักพัฒนาเว็บจะต้องมีส่วนร่วมในระดับหนึ่งเพื่อให้เป็นไปตามข้อกำหนดการช่วยเหลือพิเศษดังกล่าว เช่น
- สำหรับฟีเจอร์ที่ขาดหายไป คุณสามารถติดตั้งใช้งานฟีเจอร์ดังกล่าวภายในโค้ดเบสได้ แม้ว่าจะใช้ไลบรารีที่เป็นปัญหาต่อไป
- คุณสามารถมีส่วนร่วมในฟีเจอร์ที่ขาดหายไปดังกล่าวในคลังได้หากนายจ้างของคุณให้การสนับสนุน และหากผู้เขียนคลังอนุญาต
- คุณสามารถเปิดกล่องโต้ตอบกับผู้เขียนคลัง ตัวอย่างเช่น ฟีเจอร์การช่วยเหลือพิเศษที่เฉพาะเจาะจงเหล่านี้อยู่ในแผนพัฒนาของคุณไหม คุณเห็นด้วยไหมว่าเนื้อหาดังกล่าวควรอยู่ในคลัง
- สำหรับกรณีการใช้งานยอดนิยม คุณสามารถสำรวจตัวเลือกไลบรารีทางเลือกที่เข้าถึงได้ง่ายขึ้น ซึ่งอาจมีอยู่แต่หายาก
- ในกรณีที่รุนแรง คุณอาจต้องเลิกใช้ไลบรารีทั้งหมดและใช้ฟีเจอร์ตั้งแต่ต้น กรณีนี้อาจเกิดขึ้นเมื่อไลบรารีหรือเฟรมเวิร์กมีประสบการณ์การช่วยเหลือพิเศษที่ลดลงเมื่อใช้งานครั้งแรก และคุณต้องยกเลิกการตั้งค่าจำนวนมากที่ไลบรารีหรือเฟรมเวิร์กควรจะให้ไว้กับคุณโดยไม่มีค่าใช้จ่าย
การประชุม
ไลบรารีซอฟต์แวร์ที่ใช้รูปแบบการเขียนโค้ดที่ยอมรับแล้วจะใช้งานได้ง่ายกว่า หากไลบรารีใช้รูปแบบการเขียนโค้ดที่ไม่เคยได้ยินมาก่อน คุณและทีมอาจใช้งานไลบรารีดังกล่าวได้ยาก
หากไลบรารีไม่เป็นไปตามรูปแบบการเขียนโค้ดทั่วไป (เช่น คู่มือแนะนำทั่วไป) คุณไม่สามารถดำเนินการใดๆ เป็นการแก้ไขทันทีได้ แต่ยังมีตัวเลือกอื่นๆ อยู่ 2-3 รายการ ดังนี้
- โปรดแยกความแตกต่างระหว่างซอร์สโค้ดของไลบรารีกับ API ที่แสดงให้คุณเห็นในฐานะผู้ใช้ไลบรารี แม้ว่าซอร์สโค้ดภายในอาจใช้รูปแบบที่ไม่คุ้นเคย แต่หาก API (ส่วนของไลบรารีที่คุณโต้ตอบด้วย) ใช้รูปแบบที่คุ้นเคย ก็อาจไม่ต้องกังวล
- หาก API ของไลบรารีไม่เป็นไปตามรูปแบบการเขียนโค้ดทั่วไป คุณสามารถใช้รูปแบบการออกแบบ JavaScript เช่น รูปแบบพร็อกซี เพื่อรวมและบรรจุการโต้ตอบทั้งหมดกับไลบรารีไว้ในไฟล์เดียวในโค้ดเบส จากนั้นพร็อกซีจะเสนอ API ที่ใช้งานง่ายขึ้นให้กับส่วนอื่นๆ ของโค้ดภายในโค้ดเบส
รูปแบบการใช้งานมีบทบาทสำคัญกับความสะดวกในการใช้งาน ไลบรารีที่มี API ที่ใช้งานง่ายจะช่วยประหยัดเวลาได้หลายชั่วโมงหรือหลายวันเมื่อเทียบกับ API ที่ใช้งานยากซึ่งต้องใช้เวลาทดลองมากจึงจะเข้าใจ
อัปเดต
ตัวอย่างเช่น สำหรับไลบรารีที่ทำงานได้อย่างสมบูรณ์ซึ่งทำการคํานวณทางคณิตศาสตร์เพียงไม่กี่รายการ ไลบรารีดังกล่าวอาจไม่ค่อยจําเป็นต้องอัปเดต อันที่จริงแล้ว ไลบรารีที่สมบูรณ์แบบนั้นหาได้ยากมากในโลกการพัฒนาเว็บที่เปลี่ยนแปลงอยู่ตลอดเวลา อย่างไรก็ตาม บางครั้งคุณต้องการให้ผู้เขียนไลบรารีตอบกลับและยินดีที่จะอัปเดต การวิจัยและการค้นพบใหม่ๆ อาจเผยให้เห็นวิธีทํางานที่ดีกว่า ดังนั้นเทคนิคที่ใช้ในคลังและเฟรมเวิร์กจึงอาจมีการเปลี่ยนแปลงอยู่เสมอ
เมื่อเลือกไลบรารีหรือเฟรมเวิร์ก ให้สังเกตวิธีจัดการการอัปเดต และตระหนักว่าการตัดสินใจดังกล่าวอาจส่งผลต่อคุณดังนี้
- คลังภาพมีกำหนดการเผยแพร่ที่สมเหตุสมผลไหม ตัวอย่างเช่น การอัปเดตที่เก็บซอร์สโค้ดอาจเกิดขึ้นบ่อยครั้ง แต่หากการอัปเดตดังกล่าวไม่ได้ "เผยแพร่" หรือ "เปิดตัว" คุณจะพบว่าการดาวน์โหลดการอัปเดตดังกล่าวอาจเป็นเรื่องยาก
- ไลบรารีมีการอัปเดตโดยใช้รูปแบบการกำหนดเวอร์ชันซอฟต์แวร์ที่เหมาะสมหรือไม่ ไลบรารีจะช่วยประหยัดเวลา หากต้องเปลี่ยนโค้ดโดยไม่คาดคิดทุกครั้งที่อัปเดตเวอร์ชันไลบรารี การดำเนินการนี้อาจทำให้การใช้ไลบรารีนั้นเสียเปล่า บางครั้งการเปลี่ยนแปลงที่ทำให้เกิดข้อจำกัดการใช้งานเป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ในโลกอุดมคติ การเปลี่ยนแปลงจะเกิดขึ้นไม่บ่อยนักและไม่ได้บังคับให้ผู้ใช้ไลบรารีทำตาม
- คลังพยายามทำให้เข้ากันได้แบบย้อนหลังไหม บางครั้งการอัปเดตซอฟต์แวร์อาจมาพร้อมกับการเปลี่ยนแปลงที่ทำให้เกิดข้อขัดข้อง แต่ก็อาจมีความเข้ากันได้แบบย้อนหลังด้วย ซึ่งช่วยให้ผู้ใช้ไลบรารีใช้ไลบรารีเวอร์ชันล่าสุดได้โดยเปลี่ยนแปลงโค้ดเพียงเล็กน้อย
การอนุญาตให้ใช้สิทธิ
การอนุญาตให้ใช้ซอฟต์แวร์เป็นสิ่งสำคัญในการใช้คลังซอฟต์แวร์ของบุคคลที่สาม ผู้แต่งคลังอาจมอบหมายใบอนุญาตให้กับคลังของตน หากคุณกำลังพิจารณาใช้คลัง ตัวเลือกใบอนุญาตของคลังอาจส่งผลต่อคุณ
เช่น ไลบรารี JavaScript อาจมีการอนุญาตให้ใช้สิทธิซอฟต์แวร์ที่อนุญาตให้คุณใช้ในสภาพแวดล้อมที่ไม่ใช่เชิงพาณิชย์ ตัวเลือกนี้เหมาะสำหรับโปรเจ็กต์งานอดิเรกส่วนตัว หากโปรเจ็กต์มีองค์ประกอบเชิงพาณิชย์ คุณอาจต้องพิจารณาใบอนุญาตสำหรับองค์กร
หากมีข้อสงสัย โปรดขอคำปรึกษาทางกฎหมายจากผู้เชี่ยวชาญหรือปรึกษาทีมกฎหมายภายในบริษัท
ชุมชน
ไลบรารีหรือเฟรมเวิร์กที่มีชุมชนผู้ใช้/ผู้มีส่วนร่วมจำนวนมากอาจเป็นประโยชน์ แต่ก็ไม่ได้รับประกัน โดยทั่วไปแล้ว ยิ่งไลบรารีหรือเฟรมเวิร์กมีผู้ใช้มากเท่าใด ก็ยิ่งมีโอกาสได้รับประโยชน์มากเท่านั้น ลองพิจารณาข้อดีและข้อเสียของการเข้าร่วมชุมชนนักพัฒนาแอปต่อไปนี้
ข้อดี
- ฐานผู้ใช้จำนวนมากอาจทำให้พบข้อบกพร่องได้เร็วและบ่อยครั้งมากขึ้น
- ชุมชนขนาดใหญ่ที่ใช้งานอยู่อาจหมายถึงมีบทแนะนำ คำแนะนำ วิดีโอ และแม้แต่หลักสูตรเพิ่มเติมเกี่ยวกับไลบรารีหรือเฟรมเวิร์กดังกล่าว
- ชุมชนขนาดใหญ่ที่ใช้งานอยู่อาจหมายถึงการสนับสนุนเพิ่มเติมในฟอรัมและเว็บไซต์ถามและตอบ ซึ่งจะเพิ่มโอกาสที่คำถามเกี่ยวกับการสนับสนุนจะได้รับคำตอบ
- ชุมชนที่มีส่วนร่วมอาจทำให้มีผู้มีส่วนร่วมภายนอกในไลบรารีหรือเฟรมเวิร์กมากขึ้น ซึ่งจะช่วยส่งมอบฟีเจอร์ที่ไม่ได้อยู่ในแผนพัฒนาของผู้เขียน
- เมื่อไลบรารีหรือเฟรมเวิร์กได้รับความนิยมในชุมชน ก็มีความเป็นไปได้มากขึ้นว่าเพื่อนร่วมงานและคนรอบข้างจะเคยได้ยินหรือคุ้นเคยกับไลบรารีหรือเฟรมเวิร์กดังกล่าว
ข้อเสีย
- โปรเจ็กต์ที่มีฐานผู้ใช้จำนวนมากและหลากหลายอาจกลายเป็นโปรเจ็กต์ที่ใหญ่เกินเหตุจากการเพิ่มฟีเจอร์อย่างต่อเนื่อง ไลบรารีขนาดใหญ่จะส่งผลกระทบต่อประสิทธิภาพของเว็บ
- โปรเจ็กต์ที่มีชุมชนที่มีส่วนร่วมและใช้งานอยู่อาจทำให้ผู้เขียนและผู้ดูแลโครงการเครียดได้ และอาจต้องมีการดูแลชุมชนอย่างเข้มงวด
- โปรเจ็กต์ที่เติบโตอย่างรวดเร็วแต่ไม่มีการสนับสนุนที่เหมาะสมอาจเริ่มแสดงสัญญาณว่ามีชุมชนที่เป็นพิษ ตัวอย่างเช่น มือใหม่หรือนักพัฒนาเว็บระดับเริ่มต้นอาจรู้สึกไม่ได้รับการต้อนรับในชุมชนหนึ่งๆ เนื่องจากมีการกำหนดเกณฑ์
เอกสารประกอบ
ไม่ว่าไลบรารีหรือเฟรมเวิร์ก JavaScript จะเรียบง่ายหรือซับซ้อนเพียงใด เอกสารประกอบของซอฟต์แวร์ก็ช่วยคุณได้เสมอ นักพัฒนาซอฟต์แวร์ที่มีประสบการณ์มากก็ยังใช้เอกสารประกอบแทนที่จะพยายามเขียนโค้ดเอง เอกสารประกอบจะชี้แจง API ที่คุณควรใช้และวิธีใช้
เอกสารประกอบอาจมีโค้ดตัวอย่างด้วย ซึ่งจะช่วยให้คุณเริ่มต้นใช้งานได้อย่างรวดเร็ว เมื่อประเมินไลบรารีหรือเฟรมเวิร์ก คุณอาจถามคำถามต่อไปนี้ได้
- คลังมีเอกสารประกอบไหม หากไม่ คุณจะต้องคุ้นเคยกับการแก้ปัญหาด้วยตนเอง
- เอกสารประกอบชัดเจน เข้าใจง่าย และไม่คลุมเครือหรือไม่ นักพัฒนาแอปจำนวนมากใช้เวลาไปกับเอกสารประกอบเป็นจำนวนมาก แม้ว่าจะดูเป็นเรื่องเล็กๆ แต่ความชัดเจนในเอกสารประกอบที่เป็นข้อความอาจส่งผลต่อประสิทธิภาพการทำงานเป็นอย่างมาก
- เอกสารประกอบสร้างขึ้นโดยอัตโนมัติทั้งหมดหรือไม่ เอกสารประกอบดังกล่าวอาจเข้าใจได้ยากกว่าและไม่ได้ให้คําแนะนําที่ชัดเจนเกี่ยวกับวิธีใช้ API เสมอไป
- เอกสารประกอบเป็นข้อมูลล่าสุดหรือไม่ บางครั้งการบำรุงรักษาเอกสารประกอบมักถูกมองข้าม หากอัปเดตไลบรารีแต่ไม่ได้อัปเดตเอกสารประกอบ อาจทําให้เสียเวลาในการพัฒนา
- เอกสารประกอบครอบคลุมและพร้อมใช้งานในหลายรูปแบบหรือไม่ คู่มือผู้ใช้ โค้ดตัวอย่าง เอกสารอ้างอิง การสาธิตแบบเรียลไทม์ และบทแนะนำล้วนเป็นรูปแบบเอกสารที่มีคุณค่าซึ่งจะช่วยให้คุณใช้งานไลบรารีหรือเฟรมเวิร์กได้อย่างประสบความสำเร็จ
เอกสารประกอบอาจไม่สมบูรณ์เสมอไป ซึ่งไม่ใช่เรื่องที่ต้องกังวล คุณจะต้องประเมินความต้องการขององค์กร ข้อกำหนดของโปรเจ็กต์ และความซับซ้อนของซอฟต์แวร์ แล้วใช้ข้อมูลดังกล่าวเพื่อกำหนดระดับของเอกสารประกอบที่ต้องการ
บทสรุป
เป็นเรื่องปกติที่คุณจะรู้สึกสับสนเมื่อเลือกไลบรารีหรือเฟรมเวิร์กเป็นครั้งแรก เช่นเดียวกับเรื่องอื่นๆ ยิ่งคุณเรียนรู้และฝึกฝนงานมากเท่าไร ก็ยิ่งเก่งขึ้นเท่านั้น คุณอาจต้องดูโพสต์นี้เมื่อเลือกไลบรารีหรือเฟรมเวิร์กที่จะใช้ครั้งถัดไป คุณสามารถใช้ส่วนหัวภายในโพสต์นี้เป็นรายการตรวจสอบได้ เช่น คลังนี้มีประสิทธิภาพไหม ไลบรารีนี้เป็นไปตามมาตรฐานธุรกิจของฉันสำหรับการช่วยเหลือพิเศษบนเว็บหรือไม่
ยังมีแง่มุมอื่นๆ ของไลบรารีและเฟรมเวิร์กที่คุณอาจต้องพิจารณาด้วย ซึ่งไม่ได้กล่าวถึงในบทความนี้มากนัก
- ความสามารถในการขยาย: การขยายไลบรารีด้วยตรรกะและ/หรือลักษณะการทำงานที่กำหนดเองนั้นง่ายเพียงใด
- เครื่องมือ: ไลบรารีมีเครื่องมือ เช่น ปลั๊กอินเครื่องมือแก้ไขโค้ด เครื่องมือแก้ไขข้อบกพร่อง และปลั๊กอินระบบการสร้าง (หากมี) หรือไม่
- สถาปัตยกรรม: โค้ดที่เขียนอย่างสะอาดเป็นสิ่งสำคัญ แต่สถาปัตยกรรมโดยรวมของไลบรารีมีความเหมาะสมหรือไม่
- การทดสอบ: โปรเจ็กต์มีชุดทดสอบไหม เว็บไซต์ของโปรเจ็กต์ใช้ป้ายหรือตัวบ่งชี้ที่ชุดทดสอบผ่านกับคอมมิตล่าสุดหรือไม่
- ความเข้ากันได้: ไลบรารีทำงานร่วมกับไลบรารีและ/หรือเฟรมเวิร์กอื่นๆ ที่คุณใช้อยู่ในปัจจุบันได้ดีไหม
- ต้นทุน: เฟรมเวิร์กมีต้นทุนเท่าใด ซอฟต์แวร์ดังกล่าวเป็นโอเพนซอร์สหรือมีให้ซื้อ
- เมตริกที่ไม่เกิดประโยชน์: ควรจัดให้อยู่ในลำดับท้ายๆ ของรายการเกณฑ์ หรืออาจละเว้นไปเลย แต่คุณอาจพิจารณา "การโหวต" ของโปรเจ็กต์ บัญชีโซเชียลมีเดียที่แสดงถึงโปรเจ็กต์ และ/หรือจำนวนข้อบกพร่อง/ปัญหาที่ยังไม่ได้รับการแก้ไขในหน้าโปรเจ็กต์