Laravel 2026: ทำไมการสร้าง Custom Framework ถึงมีประโยชน์
เจาะลึกโปรเจกต์ Soft PHP MVC ที่มี 405 คอมมิชชัน 813 เทสต์ และเหตุผลที่การสร้างเฟรมเวิร์กเองช่วยให้เข้าใจระบบลึกซึ้งกว่าเดิม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การสร้าง Custom Framework ไม่ใช่เพื่อแข่งกับ Laravel แต่เพื่อเรียนรู้ระบบภายใน
- โปรเจกต์ Soft PHP MVC ใช้เวลา 18 เดือน มี 405 คอมมิชชัน และ 813 เทสต์
- การทำ ORM และระบบอื่นด้วยตัวเองช่วยลดความลึกลับของเทคโนโลยี
- ความเข้าใจเชิงลึกทำให้กลายเป็นผู้ใช้งาน Laravel ที่เก่งขึ้น
คำถามที่พบบ่อยที่สุดและสมเหตุสมผลที่สุดในการพัฒนาซอฟต์แวร์คือเหตุใดจึงต้องเสียเวลาสร้างเฟรมเวิร์กขึ้นมาเองในเมื่อมี Laravel อยู่แล้ว Laravel มีระบบนิเวศขนาดใหญ่ ชุมชนผู้ใช้งานมหาศาล และแพ็กเกจรองรับทุกความต้องการ การเลือกสร้างทุกอย่างจากศูนย์จึงดูเหมือนเป็นความเย่อหยิ่งที่ต้องการจะคิดค้นล้อเกวียนขึ้นมาใหม่เพื่อให้รู้ว่าทำได้
แต่มุมมองนี้แฝงสมมติฐานที่ว่าเป้าหมายของซอฟต์แวร์คือความโปรดักทีฟเสมอ และคุณค่าของโปรเจกต์วัดกันที่ฟีเจอร์ต่อชั่วโมง ซึ่งเป็นเรื่องเข้าใจได้ในแวดวงการทำงานจริงที่เวลา เงิน และลูกค้ามีกำหนดเวลาที่กระชั้นชิด ทว่านั่นไม่ใช่สมมติฐานเดียวที่เป็นไปได้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สำหรับโปรเจกต์ส่วนตัวและพอร์ตโฟลิโอ ความโปรดักทีฟไม่ใช่เกณฑ์วัดหลัก แต่เกณฑ์วัดคือความเข้าใจอย่างลึกซึ้งว่าเครื่องมือทำงานอย่างไรตั้งแต่ ORM ไปจนถึงระบบ routing ซึ่งสิ่งเหล่านี้ไม่สามารถเรียนรู้ได้จากการใช้งานเฟรมเวิร์กสำเร็จรูป แต่มาจากการลงมือสร้างมันขึ้นมาเอง
แนวคิดของอัลเฟรด คอร์ซีบสกี ที่ว่าแผนที่ร่องรอยไม่ใช่ตัวอาณาเขตจริง เปรียบได้กับการใช้ Laravel ที่เปรียบเสมือนการมีแผนที่ชั้นยอด แต่การสร้างเฟรมเวิร์กเองคือการออกไปสำรวจพื้นที่จริงจนค้นพบว่าเส้นทางถูกสร้างขึ้นมาเพราะเหตุใด และมีอะไรอยู่นอกเหนือจากแผนที่ที่จำกัดไว้
เมื่อนักพัฒนาลงมือเขียน ORM จากศูนย์ จะได้เรียนรู้ว่าระบบ tracking การเปลี่ยนแปลงข้อมูลไม่ใช่เรื่องเวทมนตร์ แต่มันคืออาร์เรย์ที่เปรียบเทียบค่าตั้งต้นกับค่าปัจจุบัน และการเขียน query builder ก็เป็นความจำเป็นทางปฏิบัติเพื่อประกอบคำสั่งซับซ้อนโดยไม่ต้องต่อสตริง SQL เข้าด้วยกัน
"การสร้าง custom framework เป็นการพิสูจน์ความสามารถที่ไม่ใช่แค่บอกว่าฉันใช้เครื่องมือเป็น แต่บอกว่าฉันสร้างเครื่องมือขึ้นมาได้"
Dev.to
การพัฒนาเฟรมเวิร์กของตนเองช่วยฝึกทักษะการตัดสินใจทางสถาปัตยกรรมซอฟต์แวร์ (Software Architecture) ซึ่งนักพัฒนาที่ทำงานกับเฟรมเวิร์กสำเร็จรูปตลอดเวลาอาจไม่มีโอกาสได้สัมผัส การเลือกใช้ Singleton แทน DI Container หรือการเลือกใช้ไฟล์แคชแทน Redis ล้วนเป็นบทเรียนสำคัญที่สอนให้รู้ถึงข้อดีข้อเสียของแต่ละแนวทางภายใต้ข้อจำกัดเฉพาะตัว
โปรเจกต์ Soft PHP MVC ได้พิสูจน์สิ่งนี้ผ่านตัวเลข 26 คำสั่ง CLI, การจัดการฐานข้อมูลสี่ประเภท, ระบบเข้ารหัส libsodium, และการป้องกัน CSRF ด้วย HMAC ซึ่งทั้งหมดไม่ได้ถูกสร้างขึ้นมาเพื่อใช้งานจริงในเชิงพาณิชย์ แต่เพื่อรับรองว่าทุกองค์ประกอบได้รับการออกแบบและเข้าใจอย่างแท้จริง
พาราด็อกซ์นี้จะหมดไปเมื่อเลิกมอง Custom Framework เป็นคู่แข่งของ Laravel และมองมันเป็นสิ่งเติมเต็ม โดย Laravel คือเครื่องมือสำหรับงานลูกค้าที่ต้องการความเร็ว ส่วนโปรเจกต์สร้างเองคือห้องทดลองเพื่อการเรียนรู้ที่ปลอดภัย
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น