วิกฤตซอฟต์แวร์

 (wryl.tech)
1 คะแนน โดย GN⁺ 2024-07-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

วิกฤตซอฟต์แวร์

  • วิกฤตซอฟต์แวร์คืออะไร?

    • คำว่า "วิกฤตซอฟต์แวร์" ถูกใช้เป็นครั้งแรกในการประชุมวิศวกรรมซอฟต์แวร์ของ NATO ครั้งแรกในปี 1968
    • การประชุมเหล่านี้เป็นหนึ่งในความพยายามระยะแรก ๆ ในการนิยามและทำให้แนวปฏิบัติการเขียนโปรแกรมเป็นระบบ
    • การประชุมวิศวกรรมซอฟต์แวร์ของ NATO ครั้งสุดท้ายจัดขึ้นในช่วงเวลาเดียวกับการปล่อยยาน Apollo 11 ในปี 1969

  • สาเหตุของวิกฤตซอฟต์แวร์

    • Edsger Dijkstra ผู้ได้รับรางวัลทัวริงในปี 1972 อธิบายว่าสาเหตุของวิกฤตซอฟต์แวร์มาจากความซับซ้อนและความเร็วของฮาร์ดแวร์ที่เพิ่มขึ้น
    • "ยิ่งเครื่องจักรทรงพลังขึ้น ปัญหาการเขียนโปรแกรมก็ยิ่งใหญ่ขึ้น" - Edsger Dijkstra

  • วิกฤตซอฟต์แวร์ในปัจจุบัน

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

  • ปัญหาของนามธรรม

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

  • ช่องว่างระหว่างนักพัฒนากับผู้ใช้

    • วิกฤตซอฟต์แวร์ส่งผลกระทบไม่เพียงต่อคนที่สร้างซอฟต์แวร์ แต่ยังรวมถึงคนที่ใช้งานมันด้วย
    • ผู้ใช้แทบไม่มีอำนาจควบคุมอะไรได้นอกจากสิ่งที่ผู้สร้างมอบให้
    • Alan Perlis: "ถ้าคุณมีไอเดียที่ดี คุณก็ควรพร้อมที่จะรับผิดชอบมัน"

  • การขาดความรับผิดชอบ

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

  • แนวทางแก้ไข

    • แนวทางแก้วิกฤตซอฟต์แวร์ไม่ใช่การย้อนกลับไปสู่แพลตฟอร์มที่จำกัดกว่าเดิม แต่คือการจำกัดจำนวนชั้นของนามธรรมและกำหนดให้มีการคงไว้ซึ่งข้อมูล
    • โมเดลการเขียนโปรแกรม ส่วนติดต่อผู้ใช้ และฮาร์ดแวร์พื้นฐาน ควรตื้นและประกอบต่อได้
    • ควรมอบอำนาจให้กับผู้ใช้เครื่องมือ

  • ความเคลื่อนไหวในปัจจุบัน

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

สรุปโดย GN⁺

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

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

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

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

  • ความเห็นของผู้เขียน

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

  • วิกฤตซอฟต์แวร์

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

  • การพัฒนาซอฟต์แวร์และภาวะผู้นำ

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

  • ความจำเป็นของ abstraction

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

  • เครื่องมือและข้อมูล

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

  • GUI และความสามารถในการประกอบร่วมกัน

    • เมื่อใช้เครื่องมือ UNIX จะได้ประสบการณ์ที่ตื้นและประกอบร่วมกันได้
    • GUI ไม่สื่อสารกันเอง และไม่สามารถประกอบร่วมกันได้
    • กำลังทดลองเครื่องมือที่ผสาน GUI เข้ากับ shell pipeline

  • ความสำคัญของซอฟต์แวร์

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

  • โมดูลาร์ริตีและ abstraction

    • ระบบที่ซับซ้อนอย่างอินเทอร์เน็ตคงอยู่ได้ด้วย abstraction แบบแบ่งชั้น
    • เครื่องมือซอฟต์แวร์พัฒนาขึ้นอย่างมากนับตั้งแต่ยุค 70
    • ตัวอย่างเช่น ใช้ copilot ของ VSCode ก็สามารถทำ autocomplete ให้ทั้ง API ได้

  • วิกฤตการบริหารโครงการ

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