- แม้เครื่องมือ AI จะเพิ่มผลิตภาพในการพัฒนาและศักยภาพของทีม แต่ คุณภาพและเสถียรภาพของซอฟต์แวร์ กลับไม่ได้ดีขึ้นตาม ทำให้ผู้ใช้เริ่มคาดไว้ก่อนว่าหลังอัปเดตจะเจอประสบการณ์ที่แย่ลง
- บั๊กในชีวิตประจำวัน เช่น แอปธนาคารที่ยืนยัน FaceID ซ้ำ ๆ, Slack ที่ดึงโฟกัสไปเอง, การยื่นขอประกัน LG ที่ล้มเหลว, ข้อผิดพลาดของระบบอินโฟเทนเมนต์ในรถยนต์ รบกวนทั้งการเงิน งาน การสนับสนุนลูกค้า และการขับรถ
- ต่างจากอดีตที่เรียบง่ายกว่า ปัจจุบันมี abstraction ใหม่ ๆ, เฟรมเวิร์กฟรอนต์เอนด์ และความซับซ้อนของโครงสร้างพื้นฐานสะสมเพิ่มขึ้น เมื่อประกอบกับมาตรฐานประสบการณ์ผู้ใช้ที่สูงขึ้น ระบบจึงยิ่ง เปราะบาง มากขึ้น
- แม้จะมีโมเดลล่าสุดและงบประมาณโทเคนเพียงพอ การปรับปรุงเสถียรภาพก็ยากที่จะโดดเด่นใน KPI หรือสไลด์นำเสนอ บริษัทจึงให้ความสำคัญกับ ฟีเจอร์ใหม่และการออกแบบใหม่ มากกว่าการแก้บั๊ก
- ขณะที่บริษัทต่าง ๆ สะสมหนี้ AI นักพัฒนารายบุคคลกลับมีโอกาสลองสร้างซอฟต์แวร์ที่ในอดีตทำได้ยาก และกระแสต่อต้าน macOS กับ Windows อาจขยายไปสู่ การปรับปรุงซอฟต์แวร์ในชีวิตประจำวัน
ประสบการณ์ผู้ใช้ที่แย่ลงแม้ในยุค AI
- ท่ามกลางกระแส AI ผู้คนใช้โทเคนอย่างเกินจำเป็นเพื่อคว้ามูลค่าในตลาดก่อนที่ทุกอย่างจะถูกทำให้เป็นอัตโนมัติ
- ประสิทธิภาพของโมเดลที่ดีขึ้น การเลิกจ้างโปรแกรมเมอร์ที่เกิดขึ้นต่อเนื่อง และการคาดการณ์ว่า AI จะเขียนโค้ดได้ 100% ภายในสิ้นปี ยิ่งเพิ่มความกังวล
- ยุคของเอเจนต์ ให้คำมั่นถึงผลิตภาพและคุณภาพที่สูงขึ้น
- เครื่องมือใหม่ ๆ ได้เปลี่ยนวิธีสร้างและใช้งานซอฟต์แวร์ไปแล้ว
- ผู้บริหารเรียกร้องผลลัพธ์จากทีมมากขึ้น และความสามารถเฉลี่ยของทีมซอฟต์แวร์ก็อาจยกระดับขึ้นไปจากเดิมแล้ว
- แต่ผลิตภัณฑ์จริงจำนวนมากยังไม่สามารถรับประกันได้แม้แต่เสถียรภาพพื้นฐาน
- แอปธนาคารต้องให้ ล็อกอินด้วย FaceID โดยเฉลี่ยสามครั้ง กว่าหน้าจอยืนยัน 3D Secure จะปรากฏ
- Slack สำหรับ macOS เปิดขึ้นมาช้าแล้วแย่งโฟกัสจาก Ghostty ทำให้คำสั่ง
git pullที่กำลังพิมพ์ในเทอร์มินัลถูกส่งเข้าแชตกลุ่ม - การยื่นขอประกันตู้เย็น LG ล้มเหลวในขั้นตอนส่งสุดท้ายของฟอร์มหลายขั้นตอนที่มีฟิลด์จำนวนมาก และต้องเปิดดูคอนโซล JavaScript จึงจะรู้ข้อผิดพลาด
- ระบบอินโฟเทนเมนต์ในรถยนต์รีบูตทุกครั้งขณะขับหลังอัปเดต เสียงไฟเลี้ยวหายไป หรือเปิดวิทยุแทน Google Maps และการแตะหน้าจอก็หน่วงครั้งละ 1–2 วินาที
- ข้อผิดพลาดในรถยนต์ไม่ได้เป็นเพียงความไม่สะดวกด้าน UX แต่ยังลด สมาธิในการขับขี่ ด้วย
- PM ของทีมออกแบบ OS รถยนต์ใหม่ฉลองผลงานบน LinkedIn แต่ผู้ใช้จริงยังต้องต่อสู้กับผลิตภัณฑ์ต่อไป
- ทีมเหล่านั้นน่าจะมีโอกาสใช้โมเดลล่าสุดและงบประมาณโทเคนที่เหลือเฟือ และ LLM เองก็สามารถทำผลงานได้ดีมากในการ แก้บั๊ก หากได้รับโอกาส
โครงสร้างที่ความซับซ้อนและ KPI ผลักคุณภาพออกไป
- ซอฟต์แวร์มีบั๊กมาโดยตลอด และความถวิลหายุค macOS Snow Leopard ว่าเสถียรสมบูรณ์นั้นปะปนด้วย ความทรงจำแบบเลือกจำ
- หากซอฟต์แวร์ในอดีตดีกว่า เหตุผลหลักคือมันเรียบง่ายกว่าปัจจุบันมาก
- หลังจากนั้นก็มี abstraction ใหม่ ๆ, เฟรมเวิร์กฟรอนต์เอนด์ และความซับซ้อนของโครงสร้างพื้นฐานที่มากขึ้นถูกเพิ่มเข้ามา
- มาตรฐานของประสบการณ์ผู้ใช้สูงขึ้นอย่างต่อเนื่อง แต่ระบบโดยรวมกลับเปราะบางยิ่งกว่าเดิม
- การอัปเดต macOS และแอปที่พึ่งพามันกลายเป็นสิ่งที่น่ากังวลมากกว่าน่าคาดหวัง และผู้ใช้มักคาดไว้ก่อนว่าเวอร์ชันใหม่อาจแย่กว่าเดิม
- ปัญหาไม่ได้อยู่ที่ AI เองเท่ากับ การจัดลำดับความสำคัญว่าจะนำ AI ไปใช้กับอะไร
- โครงสร้างพื้นฐาน GPU มอบความสามารถอันทรงพลังให้แก่นักพัฒนา แต่ยังไม่ได้ถูกใช้มากพอเพื่อสร้างซอฟต์แวร์ที่ดีกว่า
- บริษัทซอฟต์แวร์ขับเคลื่อนด้วย KPI มานาน และการเพิ่มเสถียรภาพอาจไม่สะท้อนโดยตรงในตัวเลข
- แผนหยุดฟีเจอร์ใหม่และการออกแบบใหม่ตลอดหนึ่งไตรมาสเพื่อทุ่มแก้บั๊กเพียงอย่างเดียว ยากที่จะดูโดดเด่นในสไลด์นำเสนอ
- หากลำดับความสำคัญแบบนี้ไม่เปลี่ยน คุณภาพซอฟต์แวร์ที่ลดลง ก็ย่อมดำเนินต่อไป
โอกาสที่เปิดให้กับนักพัฒนารายบุคคล
- ขณะที่บริษัทต่าง ๆ ร่วมกันติดหล่มหนี้ AI นักพัฒนารายบุคคลกลับได้โอกาสสร้างซอฟต์แวร์ที่ในอดีตอยู่นอกเหนือความสามารถของตน
- ความคาดหวังต่อ Android Auto ในรถยนต์หรือเว็บไซต์ LG นั้นต่ำ แต่ความไม่พอใจที่สะสมต่อสภาพปัจจุบันอาจกลายเป็นแรงผลักดันให้ปรับปรุงซอฟต์แวร์ในชีวิตประจำวัน
- มีกระแสต่อต้านสถานการณ์ปัจจุบันของ macOS และ Windows ปรากฏขึ้นแล้ว
- คาดหวังว่ากระแสนี้อาจแพร่ไปทั่ว สแต็กซอฟต์แวร์ทั้งหมด
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อก่อนเราอัปเดตด้วยความคาดหวังว่าจะมีฟีเจอร์ใหม่อะไรฟรี ๆ และยังไปดูความเปลี่ยนแปลงใน Fedora Workstation 45 ด้วย แต่ตอนนี้การอัปเดตโทรศัพท์ ทีวี รถยนต์ และระบบปฏิบัติการที่ไม่ใช่ Linux กลับทำให้รู้สึกกลัวก่อนเป็นอย่างแรก
กังวลว่าจะมีฟีเจอร์ที่ไม่ต้องการและการเชื่อมต่อออกไปภายนอกเพิ่มเข้ามาอีก ส่วน macOS ก็ทำให้หมดความคาดหวังไปนานแล้ว เช่น บังคับให้ต้องหาเส้นขอบโปร่งใสเล็ก ๆ เพื่อปรับขนาดหน้าต่าง
Windows 11 ดูเหมือนใช้ dark pattern ด้วยการกลับมาเสนอฟีเจอร์การเชื่อมต่อที่ไม่ต้องการหรือ ฟีเจอร์ AI อีกครั้งหลังอัปเดตความปลอดภัย
ถ้าไม่นับวิดีโอเกม ก็แทบไม่ชอบการอัปเดตซอฟต์แวร์ใด ๆ เลย และแม้แต่ Dead By Daylight สิ่งที่พอปลอบใจได้ก็มีแค่ว่าความไร้ความสามารถของ Behaviour ผู้พัฒนาถูกกักอยู่แค่ภายในเกมเท่านั้น
ซอฟต์แวร์กรรมสิทธิ์ไม่ได้ถูกสร้างเพื่อผู้ใช้อีกต่อไป แต่ FOSS บางส่วนยังคงให้ความสำคัญกับผู้ใช้ก่อน
แต่ใช้แพ็กเกจ Store/AppX ที่อัปเดตอัตโนมัติเพื่อแจกจ่าย ‘ประสบการณ์ที่เชื่อมต่อ’ แทน และเมื่อรีบูตหลังแพตช์ก็เรียก OOBE ขึ้นมาเพื่อเสนอหรือเปิดใช้ฟีเจอร์อีกครั้ง
แม้จะไม่ได้ผูกเข้ากับอัปเดตความปลอดภัยในทางเทคนิค แต่ก็ยังเป็น dark pattern ที่ไม่สนใจผู้ใช้อยู่ดี
เครื่องมือเหล่านี้ เมื่อรวมกับวัฒนธรรม ‘move fast and break things’ ของ Silicon Valley แล้ว ได้ยกระดับ ความคาดหวังของผู้บริหารต่อผลผลิตของทีม ขึ้นไป และสิ่งที่ทรมานที่สุดคือการต้องแบกรับความคาดหวังนั้น
ซอฟต์แวร์สร้างได้เร็ว แต่การจะมั่นใจว่ามันถูกต้องต้องใช้เวลามากกว่า
การสร้างโค้ดด้วย AI อาจทำให้วิศวกรที่มีประสบการณ์สร้างงานที่เมื่อก่อนใช้เวลาหนึ่งสัปดาห์ได้ภายในหนึ่งชั่วโมง แต่ไม่ได้ลด เวลาตรวจสอบความถูกต้อง ลงด้วย
นักพัฒนาหลายคนรับเอาแต่ข้อดีด้านความเร็วในการสร้าง แล้วมองข้ามต้นทุนในการตรวจสอบความเสถียร ประสิทธิภาพ และความไร้ข้อบกพร่อง อย่างไรก็ตามคุณภาพซอฟต์แวร์สำหรับคนทั่วไปที่ลดลงนั้นเกิดขึ้นมาตั้งแต่ก่อนยุค AI แล้ว
ผลลัพธ์แตกต่างกันมากตามงาน และในโปรเจกต์ระยะยาวก็ไม่ได้ขยายแบบเชิงเส้น บางครั้ง AI กลับทำให้ล่าช้ามากขึ้นด้วยซ้ำ
ถ้าไม่สนใจคุณภาพก็ทำความเร็วได้มหาศาล แต่ต่อให้ไม่มี AI หากไม่ใส่ใจคุณภาพก็ทำได้เร็วกว่ามากอยู่แล้ว
ต่อให้พัฒนานานแค่ไหน ผลลัพธ์ที่ทำงานได้ถูกต้องในหน้างานเป็นเวลา 3 เดือนก็น่าเชื่อถือกว่า ดังนั้นจึงควรปล่อยเร็วและปล่อยบ่อย
คุณภาพซอฟต์แวร์ถูกกำหนดโดย แรงจูงใจของตลาด มาโดยตลอด และ AI ก็ไม่ได้สร้างแรงจูงใจให้ทำซอฟต์แวร์ที่แข็งแกร่งขึ้นเองโดยอัตโนมัติ
ตลาดให้รางวัลกับการเลือกผลิตภัณฑ์แบบ one-stop ของ Microsoft มากกว่าแอปที่ไม่พังทุกครั้งที่อัปเดต หรือการประกอบโซลูชันอิสระหลายตัวเข้าด้วยกัน
ในอดีตทำเช่นนั้นไม่ได้เพียงเพราะสมรรถนะคอมพิวเตอร์และความรู้ยังไม่พอ และตอนนี้อุตสาหกรรมก็เหมือนค้นพบเงื่อนไขขั้นต่ำที่ทำให้ซอฟต์แวร์พอจะยืนอยู่ได้ รวมถึงขีดจำกัดของความไม่สะดวกเล็ก ๆ น้อย ๆ ที่ผู้ใช้ยอมทน
ซอฟต์แวร์ที่สมบูรณ์และถูกต้องจะถูกสร้างขึ้นก็ต่อเมื่อความเสี่ยงด้านความรับผิดทางกฎหมายจากข้อบกพร่องมีสูงเท่านั้น
Wayland ของ KDE Plasma มี การตั้งค่าระดับระบบ สำหรับควบคุมว่าหน้าต่างใดสามารถแย่งโฟกัสได้ และทำงานได้ดีมาก
ทุกครั้งที่ใช้ Mac สำหรับงานหรือพีซี Windows ก็คิดถึงฟีเจอร์นี้ เอกสารดูได้ในหัวข้อ ‘Focus stealing prevention’: https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...
เป็นสภาพแวดล้อมเหมือน Windows 7 ที่ยังค่อย ๆ ดีขึ้นต่อเนื่องและเพิ่มความสมบูรณ์ที่มีประโยชน์
NixOS มีปัญหาเก่าเรื่องการโหลดไลบรารีเป็น n² ทำให้การเริ่มโปรแกรม GUI ช้า แต่แม้บนมินิพีซี N100 ทุกอย่างก็เปิดได้ภายในประมาณ 1 วินาที และยังจัดการจอ 4K 240Hz HDR ได้ลื่นไหล
ที่สำคัญที่สุดคือคอมพิวเตอร์ทำตามที่สั่งเท่านั้น
หากผู้ใช้รอแล้วไปป้อนอินพุตอื่น นั่นอาจเป็นสัญญาณว่าไม่ต้องการให้โฟกัสไปที่แอปนั้นอีกแล้ว แต่การออกแบบดูเหมือนตั้งอยู่บน สถานการณ์เชิงบวก ที่แอปเปิดขึ้นทันทีเท่านั้น
คำแนะนำคำบนคีย์บอร์ดสัมผัสเปลี่ยนก่อนนิ้วจะแตะพอดี และใน iOS Liquid Glass หรือเว็บแอปที่ไม่เสถียร แม้แต่ปุ่มก็ยังขยับ
ยังเต็มไปด้วยป๊อปอัปและการกระตุ้นให้มีส่วนร่วมอย่าง “คุณชอบแอปนี้ไหม?”
การแย่งโฟกัสของ Windows เป็นปัญหามาตั้งแต่ปี 1995 แล้ว และการเปลี่ยนแปลงฉับพลันที่เกิดซ้ำในระดับทุก 100ms กระตุ้นรีเฟล็กซ์ตกใจของกล้ามเนื้อและระบบลิมบิกอยู่ตลอด จนผ่านไปไม่กี่ชั่วโมงร่างกายก็สั่นได้
ควรหยุดสิ่งเร้าแบบตู้สล็อตและตัวชี้วัดการมีส่วนร่วมที่ไล่ล่าจำนวนคลิก แล้วปล่อยให้ผู้ใช้จดจ่อกับงานได้
ขณะที่ผู้ใช้กำลังพิมพ์หรือโต้ตอบกับ UI ควรมี การดีบาวซ์การแย่งโฟกัส เป็นค่าเริ่มต้น เพื่อไม่ให้แอปอื่นดึงโฟกัสไปได้เด็ดขาด
แม้จะใช้ป๊อปอัป เสียง หรือไอคอนกะพริบ ก็ไม่ควรปล่อยให้แอปที่ไม่เกี่ยวกับงานที่กำลังทำอยู่มาดักรับอินพุตไป
ไม่ใช่เรื่องที่ควรต้องขอข้อยกเว้นเพียงเพราะกดปุ่มเชื่อมต่อแล้วเชื่อมต่อสำเร็จแบบ Cisco AnyConnect และเช่นเดียวกับที่เราไม่ยอมรับให้แอปเทอร์มินัลแย่ง STDIN ไป GUI ก็ไม่ควรอนุญาตเช่นกัน
อาจเป็นบั๊ก แต่ถ้าผู้ใช้คลิกหน้าต่างอื่นก่อนที่แอปจะเปิดเสร็จ ก็อาจถือเป็นฟีเจอร์ที่เหมาะสมเสียด้วยซ้ำ
อาจไม่ให้โฟกัสกับหน้าต่างใหม่ได้เหมือน X11 แต่ก็อาจไม่ใช่พฤติกรรมที่ผู้ใช้ส่วนใหญ่ต้องการ
ปัญหาแต่เดิมไม่ใช่การเขียนโค้ด แต่คือกระบวนการสร้างบางสิ่งอย่างละเอียดรอบคอบและเคร่งครัด
การพัฒนาซอฟต์แวร์เติบโตขึ้นจากการสะสมนิสัย กลไกป้องกัน และโครงสร้างที่พิสูจน์แล้วมาเป็นเวลานาน แต่ตอนนี้เรากลายเป็นเพียงอธิบายปัญหา แล้วได้ผลลัพธ์ที่ถูกสร้างเร็วเกินไปจนตรวจทานไม่ทัน และไม่รู้ด้วยซ้ำว่าปล่อยอะไรออกไป
เหมือนเฟอร์นิเจอร์งานฝีมือที่เปลี่ยนเป็นสินค้าจากโรงงาน จนไม่รู้ว่าใครทำส่วนไหนและไม่ทนทาน ซอฟต์แวร์ก็มาถึงขั้นของ การประกอบและปล่อยใช้งานโดยปราศจากความเข้าใจ
ความด้อยคุณภาพจะสะสมขึ้น แต่ก็อาจเป็นจุดเริ่มต้นของวัฏจักรที่เรากลับมาคิดอย่างจริงจังว่าจะสร้างของดีได้อย่างไรอีกครั้ง
หากไม่ตรวจทานโค้ด การให้ AI รับผิดชอบโค้ดก็ไม่ได้แย่เป็นพิเศษไปกว่าการรัน
PIPหรือNPM installโดยไม่ตรวจสอบซอฟต์แวร์แย่ลงเรื่อย ๆ เพราะสมมติฐานที่ว่า การเขียนโค้ดถูกแก้ปัญหาแล้ว นั้นผิดตั้งแต่ต้น
การเขียนโค้ดมีราคาถูกมานานแล้ว และบริษัทต่าง ๆ ก็จ้างงานนอกให้คนที่ถูกที่สุดทำ แต่ความสามารถในการระบุปัญหาและออกแบบวิธีแก้เป็นคนละเรื่องกัน
โค้ดเป็น หนี้สิน มากกว่าสินทรัพย์ จึงควรเขียนเท่าที่จำเป็นขั้นต่ำเพื่อแก้ปัญหาจริง และตรงนี้ต้องมีวิศวกร
เมื่อทบทวนผลลัพธ์จาก AI และแก้ข้อผิดพลาดแล้ว เวลาที่ใช้ก็ใกล้เคียงกับการเขียนเอง จึงไม่ได้ช่วยงานมากนัก
เห็นด้วยว่าซอฟต์แวร์กำลังแย่ลง แต่จะโทษ AI อย่างเดียวไม่ได้
ความล้มเหลวในการส่งสัญญาณทีวีของสตรีมมิง ข้อผิดพลาด 500 ของเบราว์เซอร์ และจอฟ้าบนจอสัมผัสสาธารณะมีอยู่มาก่อนแล้ว
นอกจากจำนวนโปรแกรมเมอร์ที่เพิ่มขึ้นแบบทวีคูณจนกว่าครึ่งมีประสบการณ์เพียงไม่กี่ปีหรือน้อยกว่าแล้ว การฝึกอัลกอริทึมแบบเธรดเดียวอย่างเดียวก็ไม่พอจะรับมือระบบกระจาย, CQRS, event sourcing, auditability และ idempotency ได้
อีกทั้งเมื่อเจ้าของผลิตภัณฑ์ (PO) สายที่ไม่ใช่เทคนิคเข้าควบคุมวงจรชีวิต และทำให้ทีม ทำเฉพาะเส้นทางปกติของ MVP ก็เท่ากับรับประกันบั๊กและการเขียนใหม่ในอนาคต
ภาษาเปลี่ยนจาก C++ ไปเป็น Java, JavaScript, Python ที่เป็นมิตรกับผู้เริ่มต้นมากขึ้น แต่งานกลับซับซ้อนขึ้นเป็นระบบกระจายระหว่างองค์กร การทำงานตลอด 24 ชั่วโมง ผู้ใช้หลายล้านคน ความปลอดภัย และแมชชีนเลิร์นนิง
ระหว่างที่การเลื่อนตำแหน่งผู้บริหารและการรวมแผนกถูกห่อหุ้มว่าเป็น “ข่าวน่าตื่นเต้น” ความต่อเนื่องในการปรับปรุงผลิตภัณฑ์ก็หายไป
ไม่จำเป็นต้องนำ Agile ไปใช้แบบตีความตามตัวอักษรอย่างโง่เขลา และไม่ว่าจะเป็นอินฟราสตรักเจอร์หรือแอปสำหรับผู้ใช้ ก็สามารถวางแผนฟีเจอร์ที่ต้องใช้ในอีก 3, 6, 12 เดือนข้างหน้าได้จากผลิตภัณฑ์ก่อนหน้า คู่แข่ง และประสบการณ์ของทีม
เหมือนเวลาตาม GPS เรายังตรวจดูเส้นทางทั้งหมดและอีกสามขั้นตอนถัดไป Agile ไม่ได้แปลว่าต้องเพิ่งเริ่มคิดก้าวต่อไปหลังจากทำก้าวหนึ่งเสร็จแล้วเท่านั้น
หากเครื่องจักรทำเตียงได้เร็วขึ้น 150% แต่มีอัตราของเสีย 70% สิ่งที่เกิดขึ้นพร้อมกันคือสินค้าชำรุดเพิ่มขึ้น ความเชี่ยวชาญด้านงานไม้สูญหาย และแรงจูงใจกับคุณค่าการใช้งานของช่างฝีมือลดลง
ต่อให้สักวันเครื่องจักรจะพัฒนาดีขึ้น ระหว่างนั้นก็เหมือนมีผู้คนจำนวนมากต้องนอนบนเตียงห่วย ๆ
LLM ไม่สามารถอ่านและเข้าใจโค้ดเบสทั้งหมดในคราวเดียว แล้วตัดสินใจบนพื้นฐานของความเข้าใจนั้นได้
ส่วนที่ยากของการเขียนโปรแกรมไม่ใช่ฟังก์ชันหรือคลาสหนึ่งตัว แต่คือวิธีที่สิ่งต่าง ๆ โต้ตอบกันภายในระบบขนาดใหญ่ และขนาดของซอฟต์แวร์ก็ใหญ่กว่า หน้าต่างบริบทของ LLM โดยพื้นฐาน
ต่อให้หน้าต่างบริบทใหญ่ขึ้น ก็ไม่ได้หมายความว่ามันสะสมความเข้าใจได้เหมือนมนุษย์ จึงยังถือไม่ได้ว่า AI แก้ปัญหาการเขียนโค้ดแล้ว
มันมีประโยชน์สำหรับโปรเจกต์ใหม่ แต่การสร้างซอฟต์แวร์ใหม่อย่างรวดเร็วนั้นเดิมทีก็ง่ายกว่าการทำงานกับโค้ดเก่าอยู่แล้ว