การถกเถียงเรื่องซอฟต์แวร์บวมฉาบปะทุ: นักพัฒนาขัดแย้งระหว่างประสิทธิภาพกับความรวดเร็วในการผลิต

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

ความแตกแยกครั้งใหญ่: ประสิทธิภาพเทียบกับความมีประสิทธิภาพของนักพัฒนา

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

อย่างไรก็ตาม ผู้วิจารณ์โต้แย้งว่าการคิดเช่นนี้ไปไกลเกินไปแล้ว นักพัฒนาจำนวนมากรายงานความหงุดหงิดในแต่ละวันกับแอปพลิเคชันที่รู้สึกเชื่องช้าแม้จะทำงานบนฮาร์ดแวร์ทรงพลัง การสนทนาเผยให้เห็นความตึงเครียดที่เพิ่มขึ้นระหว่างความเร็วในการพัฒนาและคุณภาพประสบการณ์ผู้ใช้ ดังที่นักพัฒนาคนหนึ่งระบุเกี่ยวกับแนวทางปฏิบัติในการพัฒนาสมัยใหม่ว่า การคิดเป็นเรื่องยาก ดังนั้นผลิตภัณฑ์ใดๆ ที่ให้ข้ออ้างแก่ผู้คนเพื่อหยุดทำมันจะทำได้ค่อนข้างดี แม้ว่ามันจะสร้างความไม่สะดวกมากขึ้นเช่น framework บวมฉาบหรือ dependency เสื่อมโทรม

ข้อแลกเปลี่ยนในการพัฒนาที่ถูกหยิบยกมาพูดถึง:

• ข้อโต้แย้งที่สนับสนุนความพองตัว: การพัฒนาที่รวดเร็วขึ้น, ความเข้ากันได้ข้ามแพลตฟอร์ม, ฟีเจอร์ด้านความปลอดภัย, การรองรับการเข้าถึง
• ข้อโต้แย้งที่ต่อต้านความพองตัว: ประสิทธิภาพที่ดีกว่า, ขนาดที่เล็กลง, การเริ่มต้นที่เร็วขึ้น, ความซับซ้อนที่ลดลง, การบำรุงรักษาที่ง่ายขึ้น

ผลกระทบในโลกจริง: ตั้งแต่การบูตทันทีสู่ความล่าช้าหลายวินาที

ผลกระทบเชิงปฏิบัติของซอฟต์แวร์บวมฉาบกำลังปรากฏให้ผู้ใช้ปลายทางเห็นชัดเจนขึ้นเรื่อยๆ นักพัฒนาได้แบ่งปันการเปรียบเทียบที่ชัดเจนระหว่างประสบการณ์ในอดีตและปัจจุบัน โปรแกรมเมอร์คนหนึ่งนึกถึงตอนที่เล่น Quake 1 แบบหลายผู้เล่น ซึ่งเวลาที่ต้องการตั้งแต่ช่วงเวลาที่คุณเปิดเกมจนถึงช่วงเวลาที่คุณเข้าสู่เซิร์ฟเวอร์นั้นประมาณ 1 วินาที ในทำนองเดียวกัน ผู้ที่ชื่นชอบเกมย้อนยุคสังเกตว่าเกม Game Boy ดั้งเดิมโหลดทันทีบนฮาร์ดแวร์เช่น ModRetro Chromatic

ประสบการณ์เหล่านี้ตัดกันอย่างชัดเจนกับแอปพลิเคชันสมัยใหม่ นักพัฒนาหลายคนรายงานว่าแอป Electron บางตัวใช้หน่วยความจำหลายร้อยเมกะไบต์ โดยมีคนหนึ่งระบุว่าการอัปเดต MS Teams ล่าสุดบน MacOS ดาวน์โหลดตัวติดตั้งที่ ขอพื้นที่ดิสก์จากฉัน 1.2 GB นักพัฒนาอีกคนพบว่า Teams ใช้พื้นที่มากกว่า 5 GB บนแล็ปท็อปของพวกเขา ความแตกต่างในเวลาเริ่มต้นระหว่างแอปพลิเคชันสมัยใหม่เหล่านี้และรุ่นก่อนหน้าถูกวัดเป็นลำดับความใหญ่แทนที่จะเป็นเปอร์เซ็นต์

ตัวอย่างการเปรียบเทียบประสิทธิภาพ:

• Quake 1 (1996): ใช้เวลาประมาณ 1 วินาทีจากการเปิดโปรแกรมจนถึงเข้าสู่เกมเพลย์
• แอป Electron สมัยใหม่: มักใช้เวลาเริ่มต้นหลายวินาที
• Game Boy รุ่นดั้งเดิม: โหลดเกมได้ทันที
• Steam Deck สมัยใหม่: ใช้เวลาบูตนานหลายนาที

สงครามเฟรมเวิร์ก: Electron, React และการค้นหาทางเลือก

เทคโนโลยีเฉพาะบางอย่างได้กลายเป็นจุดสนใจหลักในการอภิปรายเรื่องการบวมฉาบ แอปพลิเคชัน Electron ซึ่งบรรจุเบราว์เซอร์เว็บทั้งตัวไว้กับแอปเดสก์ท็อป ถูกตรวจสอบอย่างใกล้ชิดเป็นพิเศษ แม้บางคนจะยอมรับว่าแอป Electron ที่ปรับแต่งดีแล้วเช่น Visual Studio Code ให้ประสบการณ์ผู้ใช้ที่ดี แต่หลายคนก็แสดงความไม่พอใจกับความต้องการทรัพยากรของเทคโนโลยีนี้

การสนทนายังขยายไปถึงเฟรมเวิร์กเว็บด้วย นักพัฒนาบางคนสนับสนุนการแบน React และเฟรมเวิร์กที่คล้ายกัน โดยให้เหตุผลว่า 99% ของเว็บไซต์จะทำงานได้ดีกว่ามากด้วย SSR และโค้ด JavaScript สองสามบรรทัดตรงนี้ตรงนั้น คนอื่นๆ ชี้ให้เห็นถึงทางเลือกใหม่ที่เกิดขึ้นเช่น Tauri ซึ่งสัญญาว่าจะมีขนาดแอปพลิเคชันที่เล็กกว่าอย่างมีนัยสำคัญ - มีศักยภาพในการลดแอป Electron ขนาด 500MB ให้เหลือเพียง 20MB

คติที่ว่า เวลาพัฒนาสำคัญกว่าประสิทธิภาพ treats ปัญหาประสิทธิภาพแย่เป็นปัญหาเดียวของซอฟต์แวร์ ในความเป็นจริงแล้ว ประสิทธิภาพที่แย่คืออาการของความซับซ้อนของซอฟต์แวร์ที่เพิ่มขึ้น

ตัวอย่างขนาดของแอปพลิเคชัน:

• Super Mario Bros. (1985): 31-40KB
• Windows 11 Calculator: ใช้ RAM ประมาณ 30MB
• แอป Electron สมัยใหม่: โดยทั่วไปอยู่ที่ 100-500MB
• ตัวติดตั้ง MS Teams: ต้องการพื้นที่ดิสก์ 1.2GB
• ทางเลือก Tauri: มีศักยภาพลดขนาดลงเหลือประมาณ 20MB

ปฏิทรีย์ของการบำรุงรักษา

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

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

สเปกตรัมของการปรับให้เหมาะสม: ตั้งแต่การปรับแต่งระดับจุลภาคไปจนถึงการเลือกเชิงสถาปัตยกรรม

การอภิปรายเผยให้เห็นการตีความที่แตกต่างกันเกี่ยวกับสิ่งที่ถือเป็นการปรับให้เหมาะสมที่เหมาะสม นักพัฒนาจำนวนมากอ้างอิงคำพูดที่มีชื่อเสียงของ Donald Knuth ที่ว่า premature optimization is the root of all evil แต่มีการถกเถียงอย่างมีนัยสำคัญเกี่ยวกับว่า premature หมายถึงอะไรจริงๆ บางคนตีความว่าหมายถึงการหลีกเลี่ยงการปรับแต่งระดับจุลภาคก่อนการทำ profiling ในขณะที่คนอื่นๆ ใช้มันเพื่อพิสูจน์การตัดสินใจทางสถาปัตยกรรมที่ให้ความสำคัญกับความเร็วในการพัฒนามากกว่าประสิทธิภาพ

นักพัฒนาที่มีประสบการณ์เน้นย้ำถึงความสำคัญของการเลือกอัลกอริทึมและโครงสร้างข้อมูลที่เหมาะสมตั้งแต่เนิ่นๆ โดยสังเกตว่าปัญหาประสิทธิภาพเล็กน้อยในเส้นทางที่ใช้งานบ่อยสามารถสะสมได้อย่างมีนัยสำคัญ ดังที่ผู้เชี่ยวชาญฐานข้อมูลคนหนึ่งสังเกตเห็น คำสั่งนี้ทำงานใน 2 มิลลิวินาที มันเร็วพอแล้ว โอเค แต่มันถูกเรียก 10 ครั้งต่อโฟลว์เพราะ ORM โง่อย่าง absurdly; ถ้าคุณลดมันลง 500 ไมโครวินาที คุณจะประหยัดได้ 5 มิลลิวินาที

อนาคตของซอฟต์แวร์ที่มีประสิทธิภาพ

แม้จะมีแอปพลิเคชันบวมฉาบอยู่ทั่วไป แต่ก็ยังคงมีความสนใจอย่างมากในการพัฒนาซอฟต์แวร์ที่มีประสิทธิภาพ นักพัฒนาที่ทำงานบนแอปพลิเคชันที่สำคัญต่อประสิทธิภาพ เช่น การแสดงภาพทางวิทยาศาสตร์ เกมเอนจิน และซอฟต์แวร์ระบบ ยังคงให้ความสำคัญกับการปรับให้เหมาะสม โครงการเช่น Datoviz สาธิตว่ายังมีตลาดสำหรับซอฟต์แวร์ที่ได้รับการปรับแต่งอย่างระมัดระวัง โดยเฉพาะในโดเมนที่ประสิทธิภาพส่งผลกระทบโดยตรงต่อความสามารถในการใช้งาน

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

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

อ้างอิง: Some software bloat is OK