เราหลงทางจากการสร้างซอฟต์แวร์ที่มีประสิทธิภาพกันไปแล้วหรือไม่?

 (rufatmammadli.medium.com)
3 คะแนน โดย GN⁺ 2024-04-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความยากลำบากของการเปิดไฟล์ Microsoft Word ใน Google Docs

  • พ่อของผู้เขียนต้องติดตั้ง Word บนโน้ตบุ๊กเพื่อทำงานกับไฟล์เอกสาร Microsoft Word
  • ผู้เขียนแนะนำ Google Docs ให้พ่อ
    • เพราะพ่อมีบัญชี Google อยู่แล้ว ใช้งานง่าย เป็นบริการบนคลาวด์ และซิงก์อัตโนมัติ
  • แต่เมื่อเปิดไฟล์เอกสารขนาดประมาณ 30MB ใน Google Docs กลับพบว่า Chrome หรือ Google Docs รับมือได้ยาก เช่น ต้องใช้เวลาหลายวินาทีกว่าข้อความที่พิมพ์จะปรากฏบนหน้าจอ
  • สุดท้ายจึงติดตั้ง LibreOffice และพบว่าทำงานได้รวดเร็วมาก

ข้อคิดเกี่ยวกับมาตรฐานซอฟต์แวร์ในปัจจุบัน

  • ผู้เขียนตั้งคำถามว่าในแง่ประสิทธิภาพแล้ว การพัฒนาซอฟต์แวร์กำลังถอยหลังอยู่หรือไม่
    • เครื่องมือ เฟรมเวิร์ก และภาษาสมัยใหม่ที่ดูยอดเยี่ยม อาจกำลังทำให้เราถอยหลังในด้านประสิทธิภาพก็ได้
  • สเปกฮาร์ดแวร์กำลังเพิ่มขึ้นเพื่อรองรับเว็บแอปและเบราว์เซอร์
    • หากมีแต่แอปเนทีฟล้วน ๆ สิ่งนี้อาจไม่จำเป็น
    • เหตุใดโทรศัพท์มือถือจึงต้องใช้ RAM 8GB หรือ 16GB
  • เว็บต้องการการเรนเดอร์แบบเนทีฟ แทนการเป็นตัวห่อของเอนจินเรนเดอร์ UI
    • เหตุผลที่แม้แต่โน้ตบุ๊กสเปกดี ๆ ก็ยังเปิดไฟล์ Word ขนาด 30MB ใน Google Docs ไม่ได้ดีนัก เป็นเพราะเบราว์เซอร์ต้องใช้หน่วยความจำและ CPU มากกว่า
  • ดูเหมือนว่าเราจะลืมวิธีสร้างแอปพลิเคชันที่ได้รับการปรับแต่ง ใช้ทรัพยากรอย่างมีประสิทธิภาพ และมีสมรรถนะที่ดีไปแล้ว ปัญหานี้ควรถูกแก้ไข
    • คอมพิวเตอร์ Apollo ในปี 1966 ที่มี RAM 2KB ส่งมนุษย์ไปดวงจันทร์ได้ แต่ในปี 2024 กลับจัดการไฟล์เอกสาร 30MB ในเบราว์เซอร์ไม่ได้
  • ทุกคนในอุตสาหกรรมวันนี้กำลังมุ่งความสนใจไปที่แอปพลิเคชัน PWA เพื่ออนาคต จึงทำให้โฟกัสไปที่เว็บ

ความสำคัญของการปรับแต่ง API

  • การปรับแต่ง API มีความสำคัญทั้งในเว็บและแอปเนทีฟ เพราะประสิทธิภาพของ API ส่งผลต่อประสิทธิภาพของแอปได้
  • ผลิตภัณฑ์ของผู้เขียนอย่าง Onradar(https://onradar.io) ช่วยเรื่องการปรับแต่งผ่านการมอนิเตอร์ API
    • Onradar มีทั้งการมอนิเตอร์ uptime ของ API และการมอนิเตอร์แบบ flow-based
    • สามารถสร้างสถานการณ์ผู้ใช้ที่เป็นไปได้ด้วย API ที่เกี่ยวข้องใน flow editor และให้ Onradar ทดสอบตลอด 24/7 ได้
    • มีการแจ้งเตือนเมื่อเกิดอินซิเดนต์

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-30
ความเห็นจาก Hacker News

สรุป:

  • Apple และ Microsoft ขัดขวางการพัฒนา native app ด้วยการบังคับให้ต้องมีบัญชีนักพัฒนา ต้องซื้อใบรับรองสำหรับเซ็นไบนารี และต้องแบ่งรายได้ ขณะที่เว็บเป็นทางเลือกที่ง่ายและถูกกว่ามาก
  • ด้วยกฎของมัวร์ ซอฟต์แวร์จึงอาศัยความก้าวหน้าของฮาร์ดแวร์มาโดยตลอดหลายทศวรรษ ซึ่งเป็นทั้งพรและคำสาป
  • นักพัฒนาชอบแพลตฟอร์มคอมพิวเตอร์สากลที่บูรณาการและเชื่อมต่อกันอย่างสมบูรณ์แบบอย่างเว็บ ส่วนผู้ใช้ก็ไม่ได้ใส่ใจมากนักหากประสิทธิภาพดีพอ การสร้างซอฟต์แวร์ที่ดีจึงไม่ใช่เรื่องสำคัญ
  • การตัดสินใจทางธุรกิจคือสาเหตุหลัก:
    1. ย้ายไปสู่คลาวด์ - บริษัทชอบการจ่ายเงินแบบสมัครสมาชิกเป็นประจำ และลูกค้าก็ไม่ต้องจ้างทีม IT เอง
    2. ลูกค้าปฏิเสธการอัปเกรดซอฟต์แวร์ on-premises ทำให้รอบการบำรุงรักษายาวขึ้นและต้องออกแพตช์ต่อเนื่องไม่รู้จบ
    3. การพัฒนาเว็บมีต้นทุนต่ำกว่าการพัฒนาให้รองรับหลายแพลตฟอร์ม
  • ช่วงต้นยุค 90 MS Word ถูกแจกจ่ายผ่านฟลอปปีดิสก์ และไฟล์ปฏิบัติการมีขนาด 2MB ทุกวันนี้วัดกันเป็น GB แต่ก็ไม่ชัดเจนว่าอะไรดีขึ้นบ้าง
  • มีซอฟต์แวร์น้ำหนักเบาอยู่ แต่ไม่ค่อยถูกเลือกใช้ มีซอฟต์แวร์น้ำหนักเบาที่ยอดเยี่ยมอย่าง Lua, SQLite, Fennel, Althttpd, Fossil, Mako Server
  • ฝั่งฟรอนต์เอนด์ หลายคนชอบทั้ง native app และเว็บเพจ แต่เว็บแอปอย่าง Tiddlywiki ก็มีข้อดีในแบบของมันเอง ถึงอย่างนั้นก็ยังใช้ทรัพยากรมากกว่า Emacs
  • เคยมีกรณีที่ตอนเปลี่ยนหน้าบน React ใช้เวลานานในการเรนเดอร์ dropdown สุดท้ายก็แก้ได้ด้วยการปรับโค้ด React
  • เมื่อบริษัทจัดหาอุปกรณ์ประสิทธิภาพสูงให้นักพัฒนา ก็เกิดปัญหาที่ทำให้ไม่ได้ทดสอบบน PC ทั่วไปที่เก่ากว่าอย่างเพียงพอ
  • มักเห็นบทความบล็อกแนว "โค้ดที่เป็นไปตามธรรมเนียม" และ "การเพิ่มประสิทธิภาพก่อนเวลาเป็นรากเหง้าของความชั่วร้าย" อยู่บ่อย ๆ จึงให้ความสำคัญกับเวลาพัฒนามากกว่า แต่เมื่อก่อนเคยมีนักพัฒนาที่เขียนโค้ดได้ดีกว่าและเร็วกว่า