เราหลงทางในการพัฒนาซอฟต์แวร์ให้มีประสิทธิภาพไปแล้วหรือไม่?
(medium.com/@rufatmammadli)- กรณีที่พยายามแก้ไข เอกสาร Word ขนาดประมาณ 30MB บนเบราว์เซอร์แล้วพบความหน่วงในการพิมพ์ ทำให้รู้สึกได้ถึงต้นทุนด้านประสิทธิภาพของเว็บแอปสมัยใหม่
- เอกสารส่วนใหญ่เป็นข้อความ มีเพียงรูปภาพและตารางบางส่วน แต่ในสภาพแวดล้อม Google Docs หรือ Chrome กลับไม่สามารถจัดการได้อย่างลื่นไหล
- เมื่อใช้ LibreOffice ที่ติดตั้งแทน Microsoft Office แบบเสียเงิน เอกสารเดียวกันทำงานได้เร็วกว่ามาก ทำให้เห็นความแตกต่างระหว่างเว็บแอปกับแอปเนทีฟอย่างชัดเจน
- เมื่อเว็บแอปพลิเคชันสมัยใหม่ต้องการหน่วยความจำและ CPU มากขึ้น จึงนำไปสู่ข้อกังวลว่าสเปกฮาร์ดแวร์ที่สูงขึ้นกำลังเกี่ยวพันกับ เว็บแอปที่ใช้ทรัพยากรหนัก
- แม้ PWA และ UI บนเบราว์เซอร์จะแพร่หลายขึ้น แต่ในด้านการใช้งานจริง การเรนเดอร์แบบเนทีฟ และการออกแบบซอฟต์แวร์ที่มีประสิทธิภาพยังคงสำคัญ
ปัญหาประสิทธิภาพของเว็บแอปที่เผยให้เห็นจากเอกสาร 30MB
- Google Docs ถูกเลือกใช้ก่อน เพราะสามารถใช้บัญชี Google และการซิงก์อัตโนมัติผ่านคลาวด์ได้
- หลังจากอัปโหลดเอกสารไปยัง Google Docs แล้วลองพิมพ์ พบว่าต้องใช้เวลาหลายวินาทีกว่าตัวอักษรจะแสดงบนหน้าจอ
- ขนาดไฟล์อยู่ที่ประมาณ 30MB และแม้จะมีรูปภาพบางส่วนกับตารางง่าย ๆ แต่ส่วนใหญ่เป็นข้อความ
- ประเมินว่า Chrome หรือ Google Docs ไม่สามารถจัดการเอกสารนี้ได้อย่างเหมาะสม
- Microsoft Office ถูกตัดออกเพราะเป็นซอฟต์แวร์เสียเงิน และเมื่อใช้ LibreOffice ที่ติดตั้งแทน เอกสารเดียวกันกลับทำงานได้รวดเร็วมาก
คำถามที่ใหญ่กว่าว่าด้วยประสิทธิภาพ
- ทำให้ต้องย้อนมองว่าเครื่องมือ เฟรมเวิร์ก และภาษาสมัยใหม่กำลังทำให้ซอฟต์แวร์หนักขึ้นในแง่ประสิทธิภาพหรือไม่
- มองว่าสเปกฮาร์ดแวร์ถูกยกระดับขึ้นเพื่อรองรับเว็บแอปพลิเคชันที่ใช้ทรัพยากรหนัก และหากมีแต่แอปเนทีฟล้วน ๆ ความต้องการเหล่านี้อาจลดลงได้
- ยกตัวอย่างสถานการณ์ที่อุปกรณ์มือถือจำเป็นต้องมี RAM 16GB เพื่อชี้ให้เห็นปัญหาการใช้ทรัพยากรของซอฟต์แวร์ที่เพิ่มขึ้น
- มองว่าเว็บไม่ควรเป็นเพียง wrapper สำหรับเอนจินเรนเดอร์ UI แบบง่าย ๆ แต่ควรมีประสิทธิภาพในระดับเดียวกับ การเรนเดอร์แบบเนทีฟ
- คอมพิวเตอร์ Apollo ในปี 1966 ทำให้การลงจอดบนดวงจันทร์เป็นไปได้ด้วย RAM 2KB แต่ในปี 2024 เบราว์เซอร์กลับยังทำงานกับเอกสารประมาณ 30MB ได้ยาก ความเปรียบต่างนี้เน้นย้ำถึงความจำเป็นของการปรับแต่งประสิทธิภาพ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
แม้อยากสร้างแอปเนทีฟ ก็รู้สึกเหมือนโดน Apple กับ Microsoft ขวางอยู่ตลอด ต้องยอมรับทั้งบัญชีนักพัฒนา ใบรับรองการเซ็นไบนารี และ ค่าคอมมิชชัน 30% จากรายได้ แบบไม่มีเหตุผลชัดเจน โดยเฉพาะฝั่ง API ของ Microsoft ก็เปลี่ยนไปจนสับสน
เลยหันไปเลือก เว็บ ที่เรียบง่ายและถูกกว่ามากกว่า
แอปที่ไม่ได้เซ็นก็ยังรันได้ทั้งบน Windows และ macOS แต่จะมีคำเตือนขึ้นบ่อยกว่า และค่าธรรมเนียม 30% ก็ใช้เฉพาะตอนใช้ Mac App Store หรือ Microsoft Store เท่านั้น โดย Microsoft Store ดูเหมือนจะไม่คิดค่าธรรมเนียมหากไม่ใช่เกมและใช้ระบบชำระเงินของตัวเอง
ส่วน Apple ผมไม่แน่ใจนัก แต่แอป Mac น่าจะทำได้โดยไม่ต้องมีบัญชีนักพัฒนา ขณะที่ iPhone ต้องมีบัญชีนักพัฒนา ราคาที่เคยเห็นคือ $99 ต่อปี และถ้าคิดจะทำแอปอย่างจริงจังก็ไม่ใช่เงินก้อนใหญ่
การจัดการ chargeback กับการคืนเงินก็มีต้นทุน และต้องใช้เวลากับงานซัพพอร์ตลูกค้าหรือจ้างคนมาทำ ถ้ารายได้ต่อปีต่ำกว่า 1 ล้านดอลลาร์ ค่าธรรมเนียมของ Apple คือ 15% ดังนั้นสำหรับแอปราคาถูกหรือแอปที่มีมูลค่าเพิ่ม Apple อาจเป็นดีลที่ดีกว่าการจัดการชำระเงินเอง
มันน่าขันตรงที่บทความนี้ถูกโพสต์บน Medium ซึ่งดาวน์โหลดข้อมูล 10.88MB สำหรับบทความยาวแค่ 265 คำ
about:processแล้วพบว่าแม้โหลดเสร็จไป 10 นาที บทความนี้ก็ยังใช้ หน่วยความจำ 239MB และ CPU 0.06~0.2% โดยราว 45% ของเวลา CPU น่าจะถูกใช้โดย Google reCAPTCHAอยากให้พวก Mozilla หรือ Google เก็บสถิติการใช้ CPU·หน่วยความจำ·พลังงานรายโดเมน แล้วเอานักพัฒนาที่ไม่สนใจประสิทธิภาพมาแฉให้ขายหน้ากันไปเลย
เว็บให้ความรู้สึกเหมือนย้อนกลับไปปี 2005 อีกครั้ง เพียงแต่คราวนี้ป๊อปอัปถูกฝังอยู่ในหน้าเว็บ
gemini://gemi.dev/bin/waffle.cgiด้วยเบราว์เซอร์ Gemini แล้ววาง URL ลงไป คนที่ไม่ได้ใช้เครือข่าย Gemini ก็แค่เปลี่ยนmedium.comใน URL เป็นscribe.ripใช่แล้ว เราหลงทางกันจริง ๆ และเหตุผลก็ง่ายมาก: เพราะเราทำได้ มันคือเส้นทางที่แรงต้านน้อยที่สุด เลยเลือกเดินทางนั้น
ซอฟต์แวร์อาศัยความก้าวหน้าของฮาร์ดแวร์แบบฟรี ๆ มาหลายสิบปี โดยเฉพาะในเว็บและแอปเดสก์ท็อป กฎของมัวร์เป็นทั้งพรและคำสาป และซอฟต์แวร์ที่เราใช้ทุกวันนี้ก็ถูกสร้างโดยคนที่เรียนรู้เทคโนโลยีในช่วงที่การอาศัยกระแสนั้นกำลังพีค
ตอนนี้คอมที่มีแรมต่ำกว่า 8GB ใช้งานแทบไม่ได้ และ 8GB เองก็พอถูไถเท่านั้น ซอฟต์แวร์ใหม่ ๆ ใช้ Electron แล้วกินแรมอย่างน้อย 1GB ทุกอย่างรวมถึงเบราว์เซอร์ใช้หน่วยความจำมากเกินเหตุ
Windows ยิ่งไม่เข้าใจเข้าไปใหญ่ ทุกครั้งที่ช่วยแม่ดูคอม แม้จะเป็น PC i5 รุ่นใหม่กับแรม 8GB ก็ยังช้ามาก ทั้งบูต เปิดโปรแกรม และอัปเดตก็กินเวลานาน ถ้าคอมเครื่องไหนบูตเกิน 1 นาที ก็อยากโยนออกนอกหน้าต่างเลย
มันไม่ได้แก้ปัญหาการ deploy แอปจากหลายภาษาและหลายสภาพแวดล้อม แต่แค่หลบไปใช้เอนจินคอนเทนเนอร์แทน ถ้าผู้ใช้ต้องการ ก็ให้ build script ที่ติดตั้งคอมไพเลอร์และเครื่องมือเองได้ แต่ทดสอบให้ดีจริง ๆ ยาก สุดท้ายเลยใช้คอนเทนเนอร์
Redbean กับ Cosmopolitan libc ดูจะใกล้เคียงที่สุดกับการ “แก้” ปัญหานี้ ถ้าผู้ใช้อยากแจกจ่ายแอปได้ง่ายและเสถียร คอนเทนเนอร์ก็ได้เปรียบในเชิงการแข่งขัน แล้วก็ต้องพ่วงทั้งดิสก์เกิน 100MB และเอนจินคอนเทนเนอร์ตามมาทันที
ตราบใดที่ยังยึดการแข่งขันระหว่างรัฐหรือบริษัทเป็นหลักการหลักของการพัฒนาเทคโนโลยี ก็ยากจะควบคุมวิกฤตระดับโลกอย่างการเปลี่ยนแปลงสภาพภูมิอากาศ การทำลายระบบนิเวศ และ AI สังหารได้ เราต้องมีการร่วมมือและความร่วมแรงร่วมใจเป็นหลักการจัดระเบียบระดับสูงสุด ส่วนการแข่งขันสร้างผลกระทบภายนอกเชิงลบขนาดมหึมาต่อโลกทั้งใบ
โปรแกรมที่เขียนด้วย Lazarus หรือก็คือ Free Pascal ทำงานได้เร็วมากแม้บน Windows รุ่นใหม่อย่าง Windows 11 การคงซอฟต์แวร์เดสก์ท็อปที่เขียนมาเพื่อจุดประสงค์เฉพาะเอาไว้ เป็นทางเลือกที่ดีที่สุดทั้งด้านความเร็วและเสถียรภาพ
ความทันสมัยทุกอย่างของซอฟต์แวร์ ทั้งฮาร์ดแวร์และเฟรมเวิร์ก ล้วนทำตัวเหมือนภาษีที่เก็บจากฟังก์ชันเดิมทั้งหมด
ความซับซ้อนไปกองอยู่ผิดที่ผิดทางอย่างสิ้นเชิง
แม้จะมีคำบ่นแบบนี้ซ้ำแล้วซ้ำเล่า แต่ในความเป็นจริงมันคือสภาพที่แทบไม่มีใครอยากเปลี่ยนอย่างจริงจัง
นักพัฒนาชอบเว็บซึ่งเป็นแพลตฟอร์มคอมพิวติ้งอเนกประสงค์ที่ผสานและเชื่อมต่อกันอย่างสมบูรณ์ ส่วนผู้ใช้ก็ดูเหมือนจะไม่ได้ใส่ใจเรื่องประสิทธิภาพมากนัก ตราบใดที่มันยังพอใช้ได้ สุดท้ายซอฟต์แวร์จึงถูกยอมรับได้แม้มันจะแย่ลง ตราบใดที่ยังไม่ทำให้ผู้ใช้หงุดหงิดเกินไป
ฝั่งผู้บริหารเองก็ไม่ได้สนใจจะสร้างซอฟต์แวร์ที่ดีกว่า หากมองว่าซอฟต์แวร์ที่ดีพอมีอยู่แล้ว เว้นแต่จะมีใครตัดสินใจว่าจำเป็นต้องเปลี่ยนแปลงครั้งใหญ่ ไม่เช่นนั้นก็จะไม่มีอะไรเปลี่ยน และแทบไม่มีแรงจูงใจให้เปลี่ยนจากมุมมองไหนเลย
คนที่ต้องดาวน์โหลดแอปขนาดใหญ่บนมือถือสัญญาณอ่อน อยู่ในพื้นที่อินเทอร์เน็ตไม่เสถียร หรือใช้เครื่องเก่าในกลุ่มรายได้น้อยและประเทศกำลังพัฒนา มักหงุดหงิดกับแอปที่ใหญ่และช้า ถ้าคุณรู้สึกว่าคนไม่สนใจประสิทธิภาพและขนาดแอป คุณอาจกำลังถามคำถามผิดกับคนผิดกลุ่มอยู่
เมื่อเวลาผ่านไป คนที่ยังบ่นกลับกลายเป็นคนส่วนน้อยที่ดูแปลกไป ส่วนที่เหลือก็อัปเกรด ยอมรับความบวม หรือไม่ก็ใช้ซอฟต์แวร์เก่าต่อไป
แต่ก็ควรมองประโยชน์ที่มากับความบวมนี้ด้วย ถ้า Google Docs เป็นแค่ของเลียนแบบ Word มันคงไม่ถูกใช้มากนัก แต่มีคนใช้เพราะมันฟรี เข้าถึงได้จากหลายอุปกรณ์ และทำงานร่วมกันได้ลื่นไหล
อีกทั้งบางอย่างที่ดูเหมือนความบวม แท้จริงแล้วคือความสะดวกที่เพิ่มขึ้น เช่น ฟอนต์แบบสัดส่วนที่ดูสวยในทุกขนาด ฟอนต์ Unicode การจัดการเอกสารที่ใหญ่กว่าหน่วยความจำ การสลับระหว่างเอกสารงานกับข้อมูลอ้างอิง และการป้องกันหน่วยความจำ ซึ่งแม้จะใช้ทรัพยากรมาก แต่ช่วยยกระดับคุณภาพชีวิต
โลกสมัยใหม่ที่อิงคลาวด์หรือกึ่งออนไลน์นั้นค่อนข้างฝืนธรรมชาติจากมุมมองผู้ใช้ และในกรณีอย่าง OpenOffice ที่ไม่มีความจำเป็นต้องหารายได้ ก็ยังคงเป็นเดสก์ท็อปแอปพลิเคชันได้
ไม่มีใครบ่นเรื่องนั้นเลย และแม้ประสิทธิภาพบางส่วนของแอปจะแย่มาก ก็แทบไม่มีคำร้องเรียนจากลูกค้า กว่าจะเริ่มมีคนบ่นก็เมื่อเวลาโหลดแตะราว 60 วินาที
ถึงอย่างนั้น ซอฟต์แวร์นั้นก็ได้รับคำชื่นชมมาก เพราะมันแก้ปัญหาที่มีคุณค่าสูงมาก โดยลดงานที่เคยใช้เวลาหนึ่งสัปดาห์ให้เหลือเพียงไม่กี่นาที เมื่อการแข่งขันรุนแรงขึ้นก็จำเป็นต้องปรับปรุง แต่คนส่วนใหญ่ไม่ได้ใส่ใจจริงจัง และมันมักอยู่ลำดับความสำคัญต่ำสุดเสมอ
ถ้าเปิด Task Manager จะรู้สึกทึ่งที่เห็นว่ามันใช้RAM แค่ 20~30MBทั้งที่ฐานข้อมูลปัจจุบันถูกโหลดขึ้นมาจำนวนมากแล้ว VLC และ Blender ก็เป็นตัวอย่างคล้ายกัน
น่าสนใจที่คนส่วนใหญ่มักโทษนักพัฒนา แต่ในโลกความเป็นจริง นี่คือการตัดสินใจทางธุรกิจทั้งหมด
การย้ายขึ้นคลาวด์เกิดขึ้นเพราะบริษัทชอบรายได้ที่มั่นคงจากการสมัครสมาชิก ขณะที่ลูกค้าองค์กรก็ไม่ต้องจ้างทีม IT เอง และยังโยนความรับผิดชอบออกไปภายนอกได้ จึงสามารถเรียกร้อง uptime สูงได้ ประสิทธิภาพนั้น แค่ให้ผู้ใช้ปลายทางรู้สึกว่า “พอใช้ได้” ก็พอ
ลูกค้าที่ปฏิเสธการอัปเกรดซอฟต์แวร์แบบ on-premise ก่อให้เกิดรอบบำรุงรักษาที่ยาวนานและแพตช์ไม่รู้จบ ส่วนแนวทางพัฒนาแบบทำครั้งเดียวบนเว็บก็คุ้มค่าทางธุรกิจกว่าการมีนักพัฒนาและผู้ทดสอบแยกตามแต่ละแพลตฟอร์ม ความเชี่ยวชาญของนักพัฒนาเพียงอย่างเดียวไม่อาจเปลี่ยนแรงผลักพื้นฐานนี้ได้
แม้จะใช้ฟีเจอร์ใหม่หวือหวาล่าสุดไม่ได้ แต่บนเครื่อง Win7 ก็ยังใช้CS4ได้ต่อไปโดยไม่ต้องจ่ายเพิ่ม
ปัญหาอยู่ที่นักพัฒนาพัฒนาบนเครื่องที่มีสมรรถนะสูงเกินกว่าที่ผู้ใช้จะซื้อได้ และไม่ใส่ใจเรื่องประสิทธิภาพกับโค้ดที่มีประสิทธิภาพ
ช่วงต้นยุค 90 ผมจำได้ว่า MS Word ใส่ได้ในฟลอปปีดิสก์ไม่กี่แผ่น และไฟล์รันหลักมีขนาด 2MB
มันทำงานได้ดีบน 386 ความถี่ 16MHz ที่มี RAM รวม 2MB
งานส่วนใหญ่ที่เราทำกันตอนนี้ ตอนนั้นก็ทำได้แล้ว แค่ยังไม่มีตัวตรวจไวยากรณ์ประมาณนั้น ทุกวันนี้วัดกันเป็นระดับ GB ใหญ่ขึ้น 1000 เท่า แต่ผมไม่แน่ใจว่าเราได้อะไรมา เราไม่เพียงหลงทาง แต่ยังไม่รู้ด้วยซ้ำว่าจุดหมายคืออะไร
ตัวอย่างเช่น แค่
dict.wordsของ Linux ก็มีขนาด 4.8MB แล้ว และ Arial Unicode เป็นฟอนต์ขนาดราว 20MBไอคอนของแอประหว่างพัฒนาชิ้นเดียวมีขนาด 400KB และตัวจัดการ Google Crashpad สำหรับรับมือการแครชก็มีหลาย MB
หน้าจอ 4K แบบ true color มีขนาดใหญ่กว่าหน้าจอ 640x480 16 สีถึง 138 เท่า
ข้างในมี Word 6 for Windows ที่ใช้งานได้ และอิมเมจที่บีบอัดด้วย gzip ก็ยังอยู่ใน 12MB
พีซีในยุคนั้นบูตได้โดยไม่ต้องมี UEFI และถ้าตั้งค่าดี ๆ Windows 3.11 ก็แทบจะเปิดขึ้นมาทันที และ Word ก็เปิดได้ทันทีเช่นกัน
ตอนนี้ Word มีฟีเจอร์เล็ก ๆ เพิ่มขึ้นมาก และมีฟีเจอร์ใหญ่ ๆ เพิ่มมาบางอย่าง แต่ผมมั่นใจว่า ถ้า Microsoft ใส่ใจจริง ก็ลดการใช้หน่วยความจำลงเหลือหนึ่งในสิบได้ เพียงแต่ไม่มีแรงจูงใจ คอมพิวเตอร์เร็วขึ้น หน่วยความจำก็เยอะขึ้น และเราไม่ได้พึ่งฟลอปปีดิสก์แล้ว จึงมีแต่ต้นทุนเพิ่มขึ้นเท่านั้น
ผมคิดว่าซอฟต์แวร์ที่พองโตขึ้นอาจมีผลกระทบต่อสิ่งแวดล้อมแบบมองข้ามไม่ได้ แต่คงไม่เปลี่ยน จนกว่าจะมีเสียงบ่นที่รุนแรงพอ หรือมีกฎหมายแบบ EU ต้านซอฟต์แวร์พองโตอะไรทำนองนั้น
ไม่นานมานี้ผมยังไปดูซอร์สของ MS Word for Windows 1.0 บน GitHub ด้วย ต้นฉบับจริงเผยแพร่อยู่ที่ Computer History Museum และดูได้ที่ https://computerhistory.org/blog/microsoft-word-for-windows-... โค้ดเป็น C ล้วน และส่วนใหญ่เป็นแอสเซมบลีด้วย แต่โค้ดรกมากจนเทียบกับมาตรฐาน C/C++ สมัยนี้ แพตเทิร์น หรือความสามารถของภาษาในปัจจุบันแทบไม่ได้เลย
ผมเคยเห็นคำพูดประมาณว่า ซอฟต์แวร์ก็เหมือนก๊าซ มันจะขยายตัวจนเต็มพื้นที่ที่มีให้
ดิสโทรแบบ live ก็คล้ายกัน เมื่อก่อนพยายามให้พอดีกับ CD-R เลยอยู่ที่ 700MB แต่ตอนนี้หาตัวที่ใส่ใน USB 2GB ได้ยากขึ้นมาก ถึงอย่างนั้นก็ดีใจที่แนวทาง “minimal” เริ่มได้รับความนิยม
Nvidia นี่ให้เราดาวน์โหลดอะไรกันแน่ ชุดโค้ดที่สร้างไว้ล่วงหน้านับพันแบบที่ไม่มีวันได้ใช้หรือเปล่า
เพียงแต่ตอนนี้ต้องเสียเวลามากขึ้นในการหาสิ่งที่ต้องการ ท่ามกลางฟีเจอร์พองโตที่ถูกเพิ่มเข้ามา
ซอฟต์แวร์แบบมินิมอลมีอยู่จริง แต่คนมักไม่ค่อยเลือกใช้ ผมใช้เวลาไม่น้อยกับการเลือก dependencies แบบอนุรักษ์นิยม แล้วมันก็นำไปสู่สแตกที่เบาและประสิทธิภาพดี
ทุกวันนี้ผมชอบเครื่องมืออย่าง Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], Mako Server[3]
เราใช้ซอฟต์แวร์ที่ยอดเยี่ยม เบา เสถียร และมีประสิทธิภาพได้ฟรี แต่ต้องออกนอกเส้นทางที่คนนิยมกันสักหน่อย ไม่ใช่สิ่งที่คุณจะได้ยินบ่อย ๆ บน Stack Overflow
สำหรับฝั่งฟรอนต์เอนด์ ผมยังรู้สึกลังเลเล็กน้อย ผมชอบ native app กับเว็บเพจมากกว่า แต่ก็ใช้ Tiddlywiki ทุกวัน และคิดว่าเว็บแอปก็มีที่ทางของมัน เพียงแต่แท็บไฟล์ Tiddlywiki ขนาด 6MB กลับใช้ RAM 155MB ขณะที่เซสชัน Emacs ที่ปรับแต่งหนักมากใช้แค่ 88MB เท่านั้น เลยเห็นด้วยกับประเด็นของผู้เขียน
[0]: https://fennel-lang.org/
[1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
[2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
[3]: https://makoserver.net/
แน่นอนว่าคุณก็ใช้มันผิดทางได้ แต่เมื่อเทียบกับภาษาอื่นส่วนใหญ่แล้ว มันแทบชวนช็อกว่าซอฟต์แวร์ที่เขียนด้วย Lua สามารถเล็กและมีประสิทธิภาพได้ขนาดไหน
ผมคิดว่าปัญหาประมาณนี้แหละ คือผู้บริหารบริษัทตัดสินใจว่านักพัฒนาต้องมีฮาร์ดแวร์ระดับท็อปเพื่อความสามารถในการแข่งขัน แล้วนักพัฒนาก็สร้างเว็บแอปบน โน้ตบุ๊กแรง ๆ RAM 128GB ที่บริษัทจัดให้
จากนั้นก็ไม่ทดสอบบนสภาพแวดล้อมแบบพีซีครอบครัวปี 2010 ของพ่อผม หรือไม่ก็ทดสอบไม่บ่อยและไม่ละเอียดพอที่จะสังเกตว่าหลายส่วนพังจนใช้งานแทบไม่ได้
แบบนั้นคุณจะเริ่มมอง mobile-first, การตอบสนองต่อหน้าจอ, พื้นที่หน้าจอที่จำกัด และปัญหาที่อาจเกิดขึ้นบนการเชื่อมต่อแย่ ๆ เป็นเรื่องสำคัญระดับต้น ๆ
ปกติแล้วถ้าคุณแจ้งปัญหานี้ให้ product owner ทราบ ก็มักจะถูกมองข้ามไป ดังนั้นหัวข้อที่สามควรแก้เป็น “เราทดสอบบนพีซีครอบครัวปี 2010 ด้วย แต่สำหรับผู้มีส่วนได้ส่วนเสียที่สำคัญกว่า มันไม่ใช่เรื่องที่เขาสนใจ”
เมื่อไม่นานมานี้มีการย้ายหน้าเก่าหน้าหนึ่งจาก HTML ล้วนและการสร้างฝั่งแบ็กเอนด์ไปเป็น React แล้วปรากฏว่าแค่เปิดดรอปดาวน์อันเดียวที่มีรายการราวพันรายการก็ใช้เวลาหลายวินาที เดิมทีทั้งหน้าเปิดได้ในประมาณ 100ms
ตอนแรกมีการเสนอให้แสดงแค่ 100 รายการแรก และให้ผู้ใช้พิมพ์ 3 ตัวอักษรก่อนค่อยเรนเดอร์ นี่แหละคือความเป็นจริงทุกวันนี้
แต่แน่นอนว่าในทางปฏิบัติคือแก้โค้ด React ที่ห่วยมากนั้นให้เรนเดอร์ได้ทันที
ถ้าเฟรมเวิร์กใหม่ทำให้ปัญหาถูกเปิดเผยชัดเจนจนมีคนมีเหตุผลพอจะลงมือแก้จริงๆ งั้นก็ยิ่งมีเหตุผลที่จะใช้เฟรมเวิร์กนั้น
พอเอาบทความอย่าง “idiomatic Ruby” หรือ “การเพิ่มประสิทธิภาพก่อนเวลาอันควรคือรากเหง้าของความชั่วร้ายทั้งมวล” มายกขึ้นมา แล้วบอกว่า “เวลาในการพัฒนาสำคัญกว่าประสิทธิภาพ” มันก็เลยออกมาเป็นแบบนี้
เมื่อก่อนเคยมีนักพัฒนาที่เขียนโค้ดได้ดีกว่าโดยใช้เวลาน้อยกว่านี้
เคยเห็นโค้ดเก่าๆ ที่เลวร้ายจนน่ากลัวอยู่เยอะ ซึ่งถ้าเป็นตอนนี้ก็คงไม่มีใครสร้างมันขึ้นมา