โพสต์โดย ShiningRay เมื่อวันที่ 3 เมษายน 2549
Edwin Martin < [email protected] >
แปลโดย: ShiningRay @ Nirvana Studio
ฉันพัฒนาแอปพลิเคชัน PHP มาเป็นเวลาสี่ปีแล้ว PHP นั้นเขียนง่ายมาก แต่ PHP ก็มีข้อบกพร่องร้ายแรงเช่นกัน
ด้านล่างนี้ฉันจะให้เหตุผลว่าทำไม PHP ไม่เหมาะสำหรับเว็บไซต์ที่มีขนาดใหญ่กว่าเว็บไซต์สมัครเล่นขนาดเล็ก
1. การสนับสนุนการเรียกซ้ำที่ไม่ดี การเรียกซ้ำเป็นกลไกสำหรับฟังก์ชันในการเรียกตัวเอง นี่เป็นคุณสมบัติที่ทรงพลังที่สามารถเปลี่ยนสิ่งที่ซับซ้อนให้กลายเป็นสิ่งที่เรียบง่ายได้ ตัวอย่างของการใช้การเรียกซ้ำคือการเรียงลำดับอย่างรวดเร็ว น่าเสียดายที่ PHP ไม่ค่อยดีนักในการเรียกซ้ำ Zeev นักพัฒนา PHP กล่าวว่า: "PHP 4.0 (Zend) ใช้วิธีการสแต็กสำหรับข้อมูลหนาแน่นมากกว่าวิธีการฮีป ซึ่งหมายความว่าจำนวนฟังก์ชันแบบเรียกซ้ำที่มันสามารถทนได้นั้นถูกจำกัดน้อยกว่าภาษาอื่นอย่างมาก" ดูข้อผิดพลาด 1901 . นี่เป็นข้อแก้ตัวที่แย่มาก ภาษาการเขียนโปรแกรมทุกภาษาควรให้การสนับสนุนการเรียกซ้ำที่ดี
2. โมดูล PHP จำนวนมากไม่ปลอดภัยต่อเธรด เมื่อไม่กี่ปีที่ผ่านมา Apache ได้เปิดตัวเว็บเซิร์ฟเวอร์เวอร์ชัน 2.0 เวอร์ชันนี้รองรับโหมดมัลติเธรด ซึ่งส่วนหนึ่งของซอฟต์แวร์สามารถเรียกใช้หลายส่วนพร้อมกันได้ ผู้ประดิษฐ์ PHP กล่าวว่าแกนหลักของ PHP นั้นปลอดภัยต่อเธรด แต่โมดูลที่ไม่ใช่แกนหลักอาจไม่ปลอดภัย แต่เก้าในสิบครั้งคุณต้องการใช้โมดูลนี้ในสคริปต์ PHP แต่นี่ทำให้สคริปต์ของคุณเข้ากันไม่ได้กับโหมดมัลติเธรดของ Apache นี่คือสาเหตุที่ทีมงาน PHP ไม่แนะนำให้ใช้ PHP ในโหมดมัลติเธรดของ Apache 2 การรองรับโหมดมัลติเธรดที่ไม่ดีของ PHP มักถูกอ้างถึงว่าเป็นสาเหตุหนึ่งที่ทำให้ Apache 2 ยังคงไม่เป็นที่นิยม
โปรดอ่านการสนทนานี้: Slashdot: ไซต์ปฏิเสธ Apache 2?.
PHP ใช้งานไม่ได้เนื่องจากเหตุผลทางธุรกิจ การใช้แคชจะทำให้ประสิทธิภาพของ PHP เพิ่มขึ้น 500% [ดูเกณฑ์มาตรฐาน] เหตุใดจึงไม่สร้างแคชไว้ใน PHP? เนื่องจาก Zend ซึ่งเป็นผู้ผลิต PHP ขาย Zend Accelerator ของตัวเอง ดังนั้นแน่นอนว่าพวกเขาไม่ต้องการทิ้งผลิตภัณฑ์เชิงพาณิชย์ของตนไป
แต่มีอีกทางเลือกหนึ่ง: APC (ต่อมา Zend ได้เปิดตัว Zend Optimizer ซึ่งเป็นตัวเร่งความเร็ว - นักแปลฟรี)
4. ไม่มีเนมสเปซ ลองนึกภาพว่ามีคนสร้างโมดูล PHP เพื่ออ่านไฟล์ ฟังก์ชันหนึ่งในโมดูลเรียกว่าอ่าน จากนั้นโมดูลของบุคคลอื่นสามารถอ่านหน้าเว็บซึ่งมีฟังก์ชันการอ่านด้วย ถ้าอย่างนั้นเราจะใช้สองโมดูลนี้พร้อมกันไม่ได้ เพราะ PHP ไม่รู้ว่าคุณต้องการใช้ฟังก์ชันไหน
แต่มีวิธีแก้ไขที่ง่ายมาก และนั่นคือเนมสเปซ มีคนเคยแนะนำให้เพิ่มฟีเจอร์นี้ใน PHP5 แต่น่าเสียดายที่เขาไม่ทำเช่นนั้น ตอนนี้ หากไม่มีเนมสเปซ แต่ละฟังก์ชันจะต้องนำหน้าด้วยชื่อโมดูล เพื่อหลีกเลี่ยงความขัดแย้งของชื่อ ส่งผลให้ชื่อฟังก์ชันยาวมาก เช่น xsl_xsltprocessor_transform_to_xml ซึ่งทำให้เขียนและเข้าใจโค้ดได้ยาก
5. อักขระรูปแบบวันที่ที่ไม่เป็นมาตรฐาน โปรแกรมเมอร์หลายคนคุ้นเคยกับอักขระรูปแบบวันที่ซึ่งมาจากภาษา UNIX และ C ภาษาโปรแกรมอื่น ๆ หลายภาษาได้นำมาตรฐานนี้มาใช้ แต่ก็น่าแปลกที่ PHP มีชุดอักขระรูปแบบวันที่ที่เข้ากันไม่ได้อย่างสมบูรณ์เป็นของตัวเอง ในภาษา C "%j" หมายถึงวันของปี และใน PHP หมายถึงวันของเดือน อย่างไรก็ตาม เพื่อให้เกิดความสับสนมากขึ้น: ฟังก์ชัน strftime และฟังก์ชัน date_format ของ Smarty (เครื่องมือเทมเพลต PHP ยอดนิยม) ใช้อักขระการจัดรูปแบบ C/UNIX
6. ใบอนุญาตที่สับสน คุณอาจคิดว่า PHP นั้นฟรี และโมดูล PHP ทั้งหมดที่กล่าวถึงในคู่มือก็เช่นกัน ผิด! ตัวอย่างเช่น หากคุณต้องการสร้างไฟล์ PDF ใน PHP คุณจะพบสองโมดูลในคู่มือ: PDF และ ClibPDF แต่ทั้งสองอย่างนี้ได้รับอนุญาตในเชิงพาณิชย์ ดังนั้นสำหรับทุกโมดูลที่คุณใช้ คุณต้องแน่ใจว่าคุณยอมรับใบอนุญาตของโมดูลนั้น
7. กฎการตั้งชื่อฟังก์ชันที่ไม่สอดคล้องกัน ชื่อฟังก์ชันบางชื่อประกอบด้วยคำหลายคำ โดยทั่วไปมีสามนิสัยของการผสมคำ:
การประกบโดยตรง: getnumberoffiles
แยกด้วยขีดล่าง: get_number_of_files
กฎของอูฐ: getNumberOfFiles
สำหรับภาษาส่วนใหญ่ ให้เลือกภาษาใดภาษาหนึ่งต่อไปนี้ แต่ใช้ PHP
ตัวอย่างเช่น หากคุณต้องการแปลงอักขระพิเศษบางตัวให้เป็นเอนทิตี HTML คุณจะต้องใช้ฟังก์ชัน htmlentities (การต่อคำโดยตรง) หากคุณต้องการใช้ฟังก์ชันตรงกันข้าม คุณต้องใช้ html_entity_decode ซึ่งเป็นน้องชายคนเล็ก ด้วยเหตุผลพิเศษบางประการ ชื่อฟังก์ชันนี้มีคำที่คั่นด้วยเครื่องหมายขีดล่าง เป็นไปได้ยังไง? คุณรู้ว่ามีฟังก์ชันที่เรียกว่า strpad หรือเขาเป็น str_pad? ทุกครั้งที่คุณต้องตรวจสอบว่าสัญลักษณ์คืออะไรหรือเพียงแค่รอข้อผิดพลาด ฟังก์ชั่นไม่คำนึงถึงขนาดตัวพิมพ์ ดังนั้นสำหรับ PHP ไม่มีความแตกต่างระหว่าง rawurldecode และ RawUrlDecode สิ่งนี้ก็ไม่ดีเช่นกันเพราะทั้งคู่ใช้กันและดูแตกต่างออกไป ทำให้ผู้อ่านสับสน
8. คำพูดอันมหัศจรรย์ คำพูดวิเศษสามารถป้องกันสคริปต์ PHP จากการโจมตีแบบแทรก SQL ได้ นี่เป็นสิ่งที่ดี แต่ด้วยเหตุผลบางประการ คุณสามารถปิดการกำหนดค่านี้ใน php.ini ได้ ดังนั้นหากคุณต้องการเขียนสคริปต์ที่ยืดหยุ่น คุณจะต้องตรวจสอบเสมอว่าเปิดหรือปิดการอ้างอิงเวทย์มนตร์ "คุณลักษณะ" ดังกล่าวควรจะทำให้การเขียนโปรแกรมง่ายขึ้น แต่จริงๆ แล้วทำให้ซับซ้อนยิ่งขึ้น
9. ขาดกรอบมาตรฐาน เว็บไซต์ที่กำลังเติบโตโดยไม่มีกรอบโดยรวมจะกลายเป็นฝันร้ายในการบำรุงรักษาในที่สุด กรอบงานสามารถทำให้งานหลายอย่างง่ายขึ้น โมเดลเฟรมเวิร์กที่ได้รับความนิยมมากที่สุดในขณะนี้คือโมเดล MVC ซึ่งแยกเลเยอร์การนำเสนอ ตรรกะทางธุรกิจ และการเข้าถึงฐานข้อมูลออกจากกัน
เว็บไซต์ PHP หลายแห่งไม่ได้ใช้โมเดล MVC พวกเขาไม่มีกรอบด้วยซ้ำ แม้ว่าตอนนี้จะมีกรอบงาน PHP อยู่บ้างและคุณสามารถเขียนได้ด้วยตัวเอง บทความและคู่มือเกี่ยวกับ PHP ไม่ได้ช่วยปรับปรุงกรอบงานสักคำ ในขณะที่นักพัฒนา JSP ใช้เฟรมเวิร์กเช่น Struts และนักพัฒนา ASP ใช้ .Net ดูเหมือนว่านักพัฒนา PHP จะเข้าใจแนวคิดเหล่านี้อย่างกว้างขวาง นี่แสดงให้เห็นว่า PHP เป็นมืออาชีพแค่ไหน
สรุป
ปัญหาคืออะไร
สำหรับโปรเจ็กต์ขนาดเล็กมาก อาจเป็นภาษาโปรแกรมที่น่าพอใจมาก แต่สำหรับโครงการขนาดใหญ่และซับซ้อนมากขึ้น PHP แสดงให้เห็นถึงจุดอ่อนของมัน เมื่อคุณสำรวจไปเรื่อย ๆ คุณจะพบวิธีแก้ไขปัญหาบางอย่างที่ฉันกล่าวถึง เมื่อรู้วิธีแก้ปัญหาแล้ว ทำไมไม่แก้ไขล่ะ? เหตุใดจึงไม่กล่าวถึงการแก้ไขเหล่านี้ในคู่มือ
เป็นเรื่องดีที่ภาษาโอเพ่นซอร์สได้รับความนิยมอย่างมาก แต่น่าเสียดายที่มันไม่ใช่ภาษาที่ดี ฉันหวังว่าปัญหาทั้งหมดจะได้รับการแก้ไขในวันหนึ่ง (อาจจะเป็น PHP6?) จากนั้นเราจะมีภาษาโอเพ่นซอร์สที่เป็นทั้งโอเพ่นซอร์สและใช้งานง่าย
ถึงตอนนี้ เมื่อคุณต้องการเริ่มโปรเจ็กต์ที่มีหน้าสคริปต์มากกว่า 5 หน้า คุณควรพิจารณา C#/ASP.Net หรือ Java/JSP หรือบางที Python ก็เป็นตัวเลือกที่ดีกว่าเช่นกัน
ที่มาของบทความนี้: http://workgroup.cn/CS/blogs/php/archive/2006/06/29/1354.aspx