ขณะที่ Taylor Otwell ผู้สร้าง Laravel มองย้อนกลับไปในช่วง 14 ปีของการพัฒนาหนึ่งใน web framework ที่ได้รับความนิยมมากที่สุดในโลก ชุมชนนักพัฒนาได้หยิบยกประเด็นความกังวลอย่างจริงจังเกี่ยวกับแนวทางของ framework ในเรื่องการบำรุงรักษาและความเข้ากันได้แบบย้อนหลัง แม้ว่า Otwell จะเน้นย้ำถึงความเรียบง่ายและการพัฒนาแบบ convention-based แต่ประสบการณ์ในโลกจริงกลับเล่าเรื่องราวที่แตกต่างออกไป
การอัปเกรดเวอร์ชันหลักพิสูจน์แล้วว่าท้าทายอย่างมาก
ชุมชน Laravel ได้ประสบกับจุดเจ็บปวดอย่างมากในช่วงการเปลี่ยนผ่านเวอร์ชันหลัก นักพัฒนารายงานว่าการย้าย codebase ขนาดใหญ่ระหว่างเวอร์ชันอาจเป็นเรื่องที่ยากลำบากอย่างมาก โดยการอัปเกรดบางครั้งใช้เวลาหลายเดือนจึงจะเสร็จสิ้น นักพัฒนาคนหนึ่งอธิบายว่าการย้าย codebase ขนาด 500,000 บรรทัดจาก Laravel 5 ไปยังเวอร์ชัน 10 เป็นกระบวนการที่ยากลำบากและใช้เวลานานมาก
การเปลี่ยนผ่านที่มีปัญหามากที่สุดเกิดขึ้นระหว่าง Laravel 3 ไป 4 และต่อมาจาก 4 ไป 5 ซึ่งการเปลี่ยนแปลงพื้นฐานของสถาปัตยกรรม framework ทำให้การอัปเกรดเป็นไปได้ยากมาก การเปลี่ยนผ่านเหล่านี้เกี่ยวข้องกับการเขียนระบบหลักใหม่ทั้งหมด การเปลี่ยนแปลงจาก snake_case เป็น CamelCase naming conventions และการปรับโครงสร้างสถาปัตยกรรมโปรเจกต์ทั้งหมด องค์กรบางแห่งพบว่าเส้นทางการอัปเกรดนั้นท้าทายมากจนเลือกที่จะคงเวอร์ชันเก่าไว้แทนที่จะพยายามทำการย้าย
ความท้าทายในการอัปเกรด Laravel เวอร์ชันหลัก:
- Laravel 3 → 4: เขียนใหม่ทั้งหมด การนำ PSR4 มาใช้ การเปลี่ยนแปลงสถาปัตยกรรมพื้นฐาน
- Laravel 4 → 5: อุปสรรคการอัปเกรดที่ใหญ่ที่สุด มักต้องเขียนแอปพลิเคชันใหม่ทั้งหมด
- Laravel 5 → 10: ยากมากสำหรับโค้ดเบสขนาดใหญ่ (500,000+ บรรทัด)
- เวอร์ชันล่าสุด (8 → 11): การอัปเกรดที่ราบรื่นกว่า แต่ยังคงต้องใช้ความพยายามอย่างมาก
ปัญหาระบบ Cache เผยให้เห็นปัญหาการบำรุงรักษาที่ลึกซึ้งยิ่งขึ้น
ปัญหาทางเทคนิคล่าสุดได้เปิดเผยปัญหาที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับแนวทางการบำรุงรักษาของ Laravel การรั่วไหลของหน่วยความจำอย่างรุนแรงในระบบ cache tagging นำไปสู่การตัดสินใจที่ก่อให้เกิดความขัดแย้งจากผู้นำของ framework เมื่อได้รับ pull request ที่สมบูรณ์เพื่อแก้ไขฟังก์ชัน cache tagging Taylor Otwell เลือกที่จะลบเอกสาร cache tagging ออกทั้งหมดแทนที่จะ merge การแก้ไข โดยอ้างเหตุผลว่าขาดความรู้ที่จะเชื่อใจโซลูชันดังกล่าว
ส่วนตัวผมไม่มีความรู้ที่จะเชื่อใจการ merge นี้ได้ ผมจึงต้องการที่จะลบเอกสาร cache tags หรือแนะนำให้ใช้กับ Memcached เท่านั้น Cache tags และ Redis เป็นฝันร้ายในเรื่องการบำรุงรักษาและความซับซ้อน
แนวทางการลบฟีเจอร์แทนที่จะแก้ไขนี้ได้ทำให้เกิดคำถามเกี่ยวกับความมุ่งมั่นของ framework ต่อความเสถียรระยะยาวและความเข้ากันได้แบบย้อนหลัง
ปรัชญา Framework แบ่งแยกชุมชนนักพัฒนา
การอภิปราย Laravel เทียบกับ Symfony เผยให้เห็นความแตกต่างทางปรัชญาพื้นฐานในแนวทางการพัฒนาเว็บ Laravel วางตำแหน่งตัวเองเป็นมิตรกับผู้เริ่มต้นพร้อมความสามารถในการพัฒนาอย่างรวดเร็ว ในขณะที่ Symfony มุ่งเน้นไปที่การบำรุงรักษาระยะยาวและแนวปฏิบัติที่ดีทางสถาปัตยกรรม นักวิจารณ์โต้แย้งว่า magic abstractions และ active record pattern ของ Laravel สร้างหนี้ทางเทคนิคที่กลายเป็นปัญหาเมื่อแอปพลิเคชันขยายขนาด
แนวทางของ framework ต่อ database models โดยเฉพาะได้รับการวิจารณ์ ไม่เหมือนกับระบบ ORM แบบดั้งเดิมที่ตาราง database แมปโดยตรงกับ PHP classes ที่มี properties ที่กำหนดไว้ Laravel ใช้ dynamic properties ที่ถูก inject ในขณะ runtime สิ่งนี้ทำให้โค้ดเข้าใจและ debug ได้ยากขึ้น ต้องใช้ปลั๊กอิน IDE พิเศษเพื่อให้ฟังก์ชัน autocomplete ทำงานได้อย่างถูกต้อง
ปรัชญา Laravel เทียบกับ Symfony:
- Laravel: เป็นมิตรกับผู้เริ่มต้น การพัฒนาอย่างรวดเร็ว การทำนายแบบ "เวทมนตร์" รูปแบบ active record
- Symfony: มุ่งเน้นองค์กร สถาปัตยกรรมที่ดูแลรักษาได้ การกำหนดค่าที่ชัดเจน รูปแบบ data mapper
- กลุ่มเป้าหมาย: Laravel ดึงดูดนักพัฒนาระดับเริ่มต้น Symfony มุ่งเป้าไปที่นักพัฒนาที่มีประสบการณ์
- ผลกระทบระยะยาว: Laravel ให้ความสำคัญกับความเร็ว Symfony เน้นความสามารถในการดูแลรักษา
โปรเจกต์เก่าต่อสู้กับข้อกำหนดสมัยใหม่
องค์กรบางแห่งยังคงใช้งาน Laravel ที่ติดตั้งมาเป็นทศวรรษ ซึ่งเน้นย้ำทั้งความน่าสนใจเริ่มแรกของ framework และความท้าทายในการอัปเกรด โปรเจกต์ที่สร้างบน Laravel 3 ซึ่งเปิดตัวในปี 2012 ยังคงใช้งานอยู่ในระบบ production แต่เผชิญกับแรงกดดันที่เพิ่มขึ้นเมื่อเวอร์ชัน PHP ก้าวหน้าและข้อกำหนดด้านความปลอดภัยพัฒนาไป ระบบเก่าเหล่านี้มักต้องการการเขียนใหม่ทั้งหมดแทนที่จะเป็นการอัปเกรดแบบค่อยเป็นค่อยไป
สถานการณ์นี้ตรงกันข้ามอย่างชัดเจนกับ framework อื่นๆ เช่น Ruby on Rails ที่นักพัฒนารายงานว่ามีเส้นทางการอัปเกรดที่ราบรื่นกว่าข้ามหลายเวอร์ชันหลัก แอปพลิเคชัน Rails มักสามารถย้ายจากเวอร์ชัน 3.2 ไปยังเวอร์ชัน 8 ได้ด้วยความพยายามที่จัดการได้ โดยรักษาความเข้ากันได้ของ API และรูปแบบที่คุ้นเคยตลอดกระบวนการ
การเปรียบเทียบเฟรมเวิร์ก - ความยากในการอัปเกรด:
- Laravel: มีการเปลี่ยนแปลงครั้งใหญ่ที่ทำลายความเข้ากันได้ระหว่างเวอร์ชัน มักต้องเขียนโค้ดใหม่ทั้งหมด
- Ruby on Rails: มีเส้นทางการอัปเกรดที่ราบรื่นกว่า รักษาความเข้ากันได้ของ API ระหว่างเวอร์ชันต่าง ๆ
- Symfony: แนวทางแบบโมดูลาร์ช่วยให้สามารถอัปเกรดคอมโพเนนต์ได้ทีละส่วน
- WordPress: รักษาความเข้ากันได้แบบย้อนหลัง แต่ยังใช้แนวทางปฏิบัติที่ล้าสมัย
สรุป
แม้ว่า Laravel จะยังคงดึงดูดนักพัฒนาใหม่ด้วย syntax ที่เข้าถึงได้และฟีเจอร์การพัฒนาอย่างรวดเร็ว แต่การบำรุงรักษาระยะยาวของ framework ยังคงเป็นประเด็นที่ก่อให้เกิดความขัดแย้ง ความตึงเครียดระหว่างความเป็นมิตรกับผู้เริ่มต้นและความเสถียรระดับองค์กรยังคงกำหนดทิศทางการอภิปรายเกี่ยวกับทิศทางอนาคตของ Laravel องค์กรที่พิจารณา Laravel สำหรับโปรเจกต์ระยะยาวต้องชั่งน้ำหนักระหว่างประโยชน์ด้านความเร็วในการพัฒนาของ framework กับความท้าทายในการย้ายและค่าใช้จ่ายการบำรุงรักษาที่อาจเกิดขึ้นเมื่อแอปพลิเคชันของพวกเขาเติบโต
อ้างอิง: Taylor Otwell: What 14 Years of Laravel Taught Me About Maintainability