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