นักพัฒนา PHP ถกเถียงเรื่องคุณค่าจริงของ Coroutines และ Fibers สำหรับการพัฒนาเว็บในชีวิตประจำวัน

ชุมชน PHP กำลังมีส่วนร่วมในการอภิปรายอย่างร้อนแรงเกี่ยวกับคุณค่าเชิงปฏิบัติของ coroutines และ fibers ในการพัฒนาเว็บในชีวิตประจำวัน แม้ว่าฟีเจอร์ขั้นสูงเหล่านี้จะสัญญาว่าจะจัดการกับการดำเนินการแบบอะซิงโครนัสได้ดีขึ้น แต่นักพัฒนาหลายคนตั้งคำถามว่าพวกมันแก้ปัญหาจริงหรือเพียงแค่เพิ่มความซับซ้อนที่ไม่จำเป็นให้กับโปรเจกต์ PHP

ความแตกแยกครั้งใหญ่: ทฤษฎีกับการปฏิบัติ

การสนทนาเผยให้เห็นความแตกแยกที่ชัดเจนในชุมชน ในด้านหนึ่ง นักพัฒนายอมรับว่า coroutines และ fibers เป็นการเพิ่มเติมที่น่าประทับใจทางเทคนิคให้กับ PHP ฟีเจอร์เหล่านี้ช่วยให้ฟังก์ชันสามารถหยุดการทำงานชั่วคราว รักษาสถานะของตัวเอง และกลับมาทำงานต่อได้ในภายหลัง - เหมาะสำหรับการจัดการหลายการดำเนินการโดยไม่ทำให้โปรแกรมทั้งหมดหยุดทำงาน ในอีกด้านหนึ่ง นักพัฒนา PHP ที่มีประสบการณ์หลายคนยอมรับว่าพวกเขาไม่เคยพบสถานการณ์ที่ฟีเจอร์เหล่านี้จะช่วยปรับปรุงงานของพวกเขาอย่างแท้จริง

ความไม่เชื่อมต่อนี้ไม่น่าแปลกใจเมื่อพิจารณาจุดแข็งแบบดั้งเดิมของ PHP ภาษานี้เจริญรุ่งเรืองด้วยสถาปัตยกรรมแบบ shared-nothing ที่แต่ละคำขอเว็บทำงานอย่างอิสระโดยไม่แบ่งปันสถานะกับคำขออื่น ๆ สำหรับเว็บแอปพลิเคชันทั่วไป - การจัดการฟอร์ม การแสดงเนื้อหา การประมวลผลข้อมูลผู้ใช้ - วิธีการนี้ทำงานได้อย่างสมบูรณ์แบบและทำให้สิ่งต่าง ๆ เรียบง่าย

วิธีการใช้งาน Coroutine ใน PHP:

• Generators: ใช้คีย์เวิร์ด yield เพื่อหยุดและเริ่มการทำงานต่อ โดยคงสถานะภายในไว้
• Fibers: การใช้งานขั้นสูงที่อนุญาตให้หยุดการทำงานได้จากจุดใดก็ได้ใน call stack
• Middleware/Filters: การทำนามธรรมระดับเฟรมเวิร์กสำหรับจัดการวงจร request/response

ปัญหาการขาด Use Cases

นักพัฒนาหลายคนในการอภิปรายชี้ให้เห็นปัญหาพื้นฐาน: ตัวอย่างส่วนใหญ่ของ coroutines และ fibers ดูเหมือนจะถูกสร้างขึ้นมาหรือเป็นวิชาการมากเกินไป แทนที่จะแสดงสถานการณ์ในโลกแห่งความเป็นจริงเช่นการจัดการกับการสืบค้นฐานข้อมูลที่ช้าหรือคำขอ API บทช่วยสอนมักจะแสดงลูปพื้นฐานหรือการดำเนินการทางคณิตศาสตร์ง่าย ๆ ที่ไม่สะท้อนถึงความท้าทายที่นักพัฒนาเว็บเผชิญจริง ๆ

ตัวอย่างทั้งหมดที่ฉันพบเป็นเหมือนตัวอย่างธรรมดา ๆ ที่นี่ที่ดูเหมือนว่าแทนที่จะยัดโค้ดจำนวนมากลงในฟังก์ชันเดียวที่ยุ่งเหยิงที่ yield คุณจะดีกว่าโดยเฉพาะจากมุมมองการวิเคราะห์แบบคงที่ในการมีการเรียกเมธอดตามลำดับหรือ callables ที่เชื่อมโยงกัน

ชุมชนดูเหมือนจะกระหายตัวอย่างเชิงปฏิบัติที่จะทำให้พวกเขาคิดว่า ว้าว ฉันสามารถใช้สิ่งนี้เพื่อแก้ปัญหา X ในโปรเจกต์จริง! น่าเสียดายที่ตัวอย่างดังกล่าวยังคงหายาก ทำให้นักพัฒนาหลายคนสงสัยเกี่ยวกับการลงทุนเวลาในการเรียนรู้ฟีเจอร์เหล่านี้

ผลกระทบการระเหยแบบเย็น

มุมมองที่น่าสนใจเกิดขึ้นเกี่ยวกับสาเหตุที่นักพัฒนา PHP ไม่เห็นความจำเป็นของฟีเจอร์เหล่านี้ บางคนโต้แย้งว่านักพัฒนาที่ต้องการความสามารถด้านการทำงานพร้อมกันขั้นสูงได้ย้ายไปใช้ภาษาอื่นแล้วในช่วงหลายปีที่ผ่านมา สิ่งนี้สร้างสิ่งที่ผู้แสดงความคิดเห็นคนหนึ่งเรียกว่าผลกระทบการระเหยแบบเย็น - ชุมชนของ PHP ประกอบด้วยนักพัฒนาที่ทำงานกับปัญหาที่ไม่ต้องการฟีเจอร์ขั้นสูงเหล่านี้โดยธรรมชาติ

ทฤษฎีนี้ชี้ให้เห็นว่า coroutines และ fibers ไม่ได้ไร้ประโยชน์ แต่ค่อนข้างนักพัฒนา PHP ทำงานในพื้นที่ที่โซลูชันที่เรียบง่ายกว่าเพียงพอ สำหรับแอปพลิเคชันที่ต้องจัดการกับการเชื่อมต่อพร้อมกันหลายพันรายการหรือการประมวลผลแบบขนานที่ซับซ้อน นักพัฒนาได้เลือกภาษาเช่น Go, Node.js หรือ Erlang แทนการรอให้ PHP ตามทัน

การรวมเข้ากับ Framework: โอกาสที่แท้จริง

แม้จะมีความสงสัยเกี่ยวกับการใช้งานโดยตรง แต่นักพัฒนาหลายคนเห็นศักยภาพในการที่ framework และไลบรารีนำฟีเจอร์เหล่านี้มาใช้เบื้องหลัง ไลบรารีเช่น AmphP ใช้ fibers อยู่แล้วเพื่อให้ API ที่สะอาดกว่าสำหรับการดำเนินการแบบอะซิงโครนัส ช่วยให้นักพัฒนาเขียนโค้ดที่ดูเหมือนซิงโครนัสแต่จริง ๆ แล้วทำงานแบบอะซิงโครนัส

วิธีการนี้อาจเป็นจุดที่เหมาะสม - ให้ผู้เขียน framework จัดการกับความซับซ้อนในขณะที่ให้ประโยชน์แก่นักพัฒนาแอปพลิเคชันโดยไม่มีภาระทางจิตใจ มันคล้ายกับที่นักพัฒนาส่วนใหญ่ไม่ทำงานโดยตรงกับการเชื่อมต่อฐานข้อมูล แต่ได้รับประโยชน์จากการแยกส่วน ORM ที่จัดการกับความซับซ้อน

ไลบรารี PHP หลักที่ใช้ Coroutines:

• AmphP: ไลบรารี Async ที่ให้ APIs ที่สะอาดสำหรับการดำเนินงานแบบ concurrent
• ReactPHP: ไลบรารีการเขียนโปรแกรมแบบ event-driven สำหรับ PHP
• Mezzio: เฟรมเวิร์กแบบ middleware-based ที่รองรับรูปแบบ coroutine
• Revolt: การใช้งาน event loop สำหรับแอปพลิเคชัน PHP

ภาพนี้แสดงให้เห็นแนวคิดของ framework ที่เชื่อมโยงกันใน PHP โดยแสดงให้เห็นว่าพวกมันสามารถทำให้ฟีเจอร์ที่ซับซ้อนอย่าง coroutine และ fiber เป็นนามธรรมเพื่อให้นักพัฒนาเข้าถึงได้ง่ายขึ้น

บริบทที่กว้างขึ้น: วิวัฒนาการของ PHP

การอภิปรายยังสัมผัสถึงวิวัฒนาการที่กำลังดำเนินอยู่ของ PHP และความท้าทายในการเพิ่มฟีเจอร์ขั้นสูงให้กับภาษาที่มีอายุ 30 ปี นักพัฒนาบางคนกังวลว่า PHP พยายามเป็นหลายสิ่งหลายอย่างมากเกินไป เพิ่มความซับซ้อนโดยไม่มีประโยชน์ที่ชัดเจนสำหรับ use case หลัก คนอื่น ๆ โต้แย้งว่าฟีเจอร์เหล่านี้จำเป็นเพื่อให้ PHP มีความสามารถในการแข่งขันและป้องกันไม่ให้นักพัฒนาเพิ่มเติมย้ายไปใช้ภาษาอื่น

การถกเถียงสะท้อนคำถามที่กว้างขึ้นเกี่ยวกับการออกแบบภาษา: ภาษาควรมุ่งเน้นไปที่จุดแข็งและยอมรับข้อจำกัด หรือควรพัฒนาอย่างต่อเนื่องเพื่อให้ตรงกับความสามารถที่พบในภาษาอื่น ๆ? วิธีการของ PHP ในการรักษาความเข้ากันได้แบบย้อนหลังในขณะที่เพิ่มฟีเจอร์ใหม่พยายามทำทั้งสองอย่าง แต่ไม่ใช่ทุกคนที่เชื่อว่ากลยุทธ์นี้ได้ผล

บทสรุป

ปฏิกิริยาที่หลากหลายของชุมชน PHP ต่อ coroutines และ fibers เน้นย้ำถึงความท้าทายในการแนะนำฟีเจอร์ขั้นสูงให้กับภาษาที่ขึ้นชื่อเรื่องความเรียบง่ายและการปฏิบัติ แม้ว่าฟีเจอร์เหล่านี้จะมีที่ยืนในแอปพลิเคชันบางประเภทอย่างไม่ต้องสงสัย แต่คุณค่าของพวกมันสำหรับการพัฒนาเว็บในชีวิตประจำวันยังคงเป็นที่สงสัยสำหรับนักพัฒนาหลายคน

การทดสอบที่แท้จริงจะเป็นว่า framework และไลบรารีสามารถแยกส่วนฟีเจอร์เหล่านี้ได้สำเร็จเพื่อให้ประโยชน์ที่ชัดเจนโดยไม่เปิดเผยความซับซ้อนที่อยู่เบื้องหลัง จนกว่าจะถึงตอนนั้น การถกเถียงน่าจะยังคงดำเนินต่อไป โดยนักพัฒนาบางคนยอมรับความเป็นไปได้ใหม่ ๆ ในขณะที่คนอื่น ๆ ยึดติดกับวิธีการที่ได้รับการพิสูจน์แล้วของ PHP ที่ได้รับใช้พวกเขามาเป็นสิบปี

อ้างอิง: Exploring Coroutines in PHP