คำเรียกร้องเพื่อซอฟต์แวร์แบบกระทัดรัดในปี 2024

 (spectrum.ieee.org)
3 คะแนน โดย GN⁺ 2024-02-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คำเรียกร้องเพื่อซอฟต์แวร์ที่กระชับสำหรับปี 2024

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

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

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

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

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

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

  • ในนวนิยายของ Vernor Vinge เรื่อง "A Deepness in the Sky" มนุษยชาติได้แพร่กระจายไปตามหมู่ดาวแล้ว แม้ยังไม่มีเทคโนโลยีที่เดินทางได้เร็วกว่าความเร็วแสง ยานอวกาศมีอายุเก่าแก่มาก และผสมปนเปเทคโนโลยีจากระบบและอารยธรรมหลากหลายแบบ

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

  • ไลบรารีส่วนใหญ่ใน npm มีฟีเจอร์มากเกินความจำเป็น ผู้เขียนไม่รู้จักการออกแบบที่ดี และทุกไลบรารีก็พยายามจะทำทุกอย่าง

    • ตัวอย่างเช่น ไลบรารีแปลงการเข้ารหัสสตริงกลับมีทั้งความสามารถโหลดไฟล์ บันทึกไฟล์ ดาวน์โหลดผ่านอินเทอร์เน็ต และมีเครื่องมือบรรทัดคำสั่งในตัว ทั้งที่ไลบรารีควรทำหน้าที่เดียวเท่านั้น
    • ดูเหมือนว่าแม้แต่ใน Rust สถานการณ์ก็ไม่ได้ดีขึ้น ถ้าจะลองแก้เอกสารของ Rust ก็ต้องติดตั้ง crate ราว 1000 ตัว
    • ปัญหาไม่ใช่ที่ภาษา แต่เป็นเพราะใครก็เผยแพร่ไลบรารีได้และก็มีคนทำจริง คนที่แค่อยาก "ให้งานเสร็จ" จะเลือกไลบรารีที่มีฟีเจอร์มากที่สุด และแทนที่จะเขียนโค้ดไม่กี่บรรทัดเพื่อแก้ปัญหานอกไลบรารี ก็กลับขอฟีเจอร์เพิ่ม
    • ไม่รู้ว่าควรแก้ปัญหานี้อย่างไร ไอเดียหนึ่งคือการตั้งกลุ่มที่สนับสนุนแนวคิด "low dependency" เพื่อกระตุ้นให้คนที่อยากติดป้ายนี้กับไลบรารีของตัวเองทำเช่นนั้น และทำให้ผู้คนมองหาป้ายนี้เวลาเลือกไลบรารี

  • ใน "Terre des Hommes" ของ Antoine de Saint-Exupéry เขาตั้งคำถามว่าเคยมองเครื่องบินสมัยใหม่ ติดตามเส้นทางวิวัฒนาการของมันในแต่ละปี และครุ่นคิดถึงทุกสิ่งที่มนุษย์สร้างขึ้นบ้างหรือไม่

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

  • ปัจจุบันโค้ดที่เราใช้งานมีปริมาณมหาศาล ตัวอย่างเช่น การเปิดประตูโรงรถอาจต้องใช้โค้ดที่ทำงานอยู่มากกว่า 50 ล้านบรรทัด

    • ทั้งที่เรารันโค้ดจำนวนมากขนาดนี้ แต่โค้ดส่วนใหญ่น่าจะไม่เคยผ่านการรีวิวอย่างลึกซึ้ง
    • และถึงอย่างนั้นเราก็ยังกลับไปใช้ชีวิตประจำวันแบบติดตั้ง npm dependency ต่อไป

  • ซอฟต์แวร์ถูกมองว่าอันตรายจนมีคนแนะนำว่าอย่ารันเอง แต่ให้ฝากไว้กับผู้ให้บริการ "X as a service" หรือ "cloud"

    • มันเหมือนกับสถานการณ์ที่บอกว่ารถยนต์ติดไฟง่ายเกินไป จึงควรให้ผู้เชี่ยวชาญที่มีนักผจญเพลิงมืออาชีพติดตามไปด้วยเป็นคนขับแทน

  • เหตุผลที่ซอฟต์แวร์ไม่กระชับขึ้นก็เพราะมันต้องใช้เวลา ทักษะ และบุคลากรราคาแพง

    • ในฐานะนักพัฒนาอิสระ คนที่เพิ่งเรียน node.js เมื่อปีที่แล้วสามารถเอา node.js, container, บริการโฮสต์ DB ของ AWS หลายแบบ, บริการ lambda, object storage, Cloudflare, yaml, react, vite และอื่น ๆ มาประกอบกันเพื่อสร้างเว็บแอปที่เปราะบางได้ภายในวันเดียว
    • ซอฟต์แวร์ที่เร็วและมีค่าบำรุงรักษาต่ำ เขียนให้ทำกำไรได้นั้นเป็นเรื่องยาก

  • ในอดีตมีความพยายามทำให้ system hook ที่ระบบจัดเตรียมไว้เป็นมาตรฐาน เพื่อให้นักพัฒนาทุกคนใช้กับอินเทอร์เฟซและส่วนอื่น ๆ ขณะที่งานหลักของนักพัฒนาคือการเขียนตรรกะของโปรแกรม

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

  • ความเห็นเกี่ยวกับ Rust คือ ต่อให้ Rust มีช่องโหว่ต่อบรรทัดน้อยกว่า C++ อยู่ 70% ถ้าใน Rust ต้องดึงแพ็กเกจมาหลายร้อยตัวและมีจำนวนบรรทัดโค้ดมากกว่า 10 เท่า จำนวนช่องโหว่แบบสัมบูรณ์ก็อาจมากกว่าอยู่ดี

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

  • พอคลิกลิงก์ก็เจอทั้งแบนเนอร์ CTA โฆษณา Google และแบนเนอร์คุกกี้ พอปิดแบนเนอร์คุกกี้ก็มีโฆษณา Google อีกอันโผล่มา และยังตามไปตอนเลื่อนหน้า ระหว่างอ่านบทความก็ต้องเห็นโฆษณาเพิ่มอีกอย่างน้อยสามชิ้น

    • ในสภาพแบบนี้ มันยากที่จะจริงจังกับเนื้อหานั้นได้