1 điểm bởi GN⁺ 2024-07-07 | 1 bình luận | Chia sẻ qua WhatsApp

Khủng hoảng phần mềm

  • Khủng hoảng phần mềm là gì?

    • Thuật ngữ "khủng hoảng phần mềm" lần đầu được sử dụng tại hội nghị kỹ nghệ phần mềm NATO đầu tiên năm 1968
    • Các hội nghị này là một trong những nỗ lực ban đầu nhằm định nghĩa và hệ thống hóa các thực hành lập trình
    • Hội nghị kỹ nghệ phần mềm NATO cuối cùng được tổ chức vào cùng thời điểm với vụ phóng Apollo 11 năm 1969
  • Nguyên nhân của khủng hoảng phần mềm

    • Edsger Dijkstra, người đoạt giải Turing năm 1972, giải thích nguyên nhân của khủng hoảng phần mềm là do độ phức tạp và tốc độ ngày càng tăng của phần cứng
    • "Máy móc càng mạnh hơn thì vấn đề lập trình cũng càng lớn hơn" - Edsger Dijkstra
  • Khủng hoảng phần mềm hiện nay

    • Hiện nay, người ta không còn nhắc nhiều đến khủng hoảng phần mềm
    • Mọi người cho rằng vấn đề đã được giải quyết nhờ sự phát triển của các ngôn ngữ mới và các phương thức tổ chức mới
    • Tuy nhiên, điều này có thể xuất phát từ cảm giác thất bại và chấp nhận hơn là sự an tâm thực sự
  • Vấn đề của trừu tượng hóa

    • Đã có nhiều nỗ lực nhằm giải quyết khủng hoảng phần mềm, nhưng phần lớn đều cố gắng xử lý vấn đề thông qua "trừu tượng hóa"
    • Trừu tượng hóa mang lại một mức độ độc lập nhất định nhưng phải đánh đổi bằng hiệu năng
    • Kể từ khi máy tính cá nhân được thương mại hóa, trừu tượng hóa đã trở thành cách tư duy cơ bản
  • Khoảng cách giữa nhà phát triển và người dùng

    • Khủng hoảng phần mềm không chỉ ảnh hưởng đến những người tạo ra phần mềm mà còn cả những người sử dụng nó
    • Người dùng hầu như không thể kiểm soát điều gì ngoài những gì tác giả cung cấp
    • Alan Perlis: "Nếu bạn có một ý tưởng hay, bạn phải sẵn sàng chịu trách nhiệm về nó"
  • Sự thiếu vắng trách nhiệm

    • Những người tạo ra phần mềm đang thoát khỏi trách nhiệm đối với các công cụ mà họ tạo ra
    • Xu hướng này càng được củng cố khi quá trình thương mại hóa diễn ra
    • Trừu tượng hóa được dùng như một công cụ để né tránh việc suy nghĩ về những vấn đề khó
  • Giải pháp

    • Giải pháp cho khủng hoảng phần mềm không phải là quay lại các nền tảng bị hạn chế hơn, mà là giới hạn số lượng lớp trừu tượng và yêu cầu bảo toàn thông tin
    • Mô hình lập trình, giao diện người dùng và phần cứng nền tảng cần phải nông và có thể cấu thành
    • Cần trao quyền cho người sử dụng công cụ
  • Những chuyển động hiện nay

    • Có những phong trào như Handmade, Permacomputing, retro computing nhằm nâng cao nhận thức về khủng hoảng phần mềm
    • Những phong trào phản văn hóa này là tín hiệu lành mạnh và cho thấy tình hình có thể trở nên tốt hơn

Tóm tắt của GN⁺

  • Khủng hoảng phần mềm là vấn đề phát sinh do độ phức tạp và tốc độ ngày càng tăng của phần cứng
  • Hiện nay người ta cố gắng giải quyết vấn đề bằng trừu tượng hóa, nhưng điều đó phải đánh đổi bằng hiệu năng
  • Những người tạo ra phần mềm đang thoát khỏi trách nhiệm đối với các công cụ họ tạo ra, và điều này càng mạnh hơn do thương mại hóa
  • Giải pháp là giới hạn số lớp trừu tượng và yêu cầu bảo toàn thông tin
  • Những phong trào như Handmade và Permacomputing đang nâng cao nhận thức về khủng hoảng phần mềm

1 bình luận

 
GN⁺ 2024-07-07
Ý kiến trên Hacker News
  • Ý kiến của tác giả

    • Phản đối việc áp dụng vô hạn, chứ không phản đối bản thân sự trừu tượng hóa
    • Không cho rằng giải pháp là quay trở lại các nền tảng bị giới hạn hơn
    • Không cho rằng người dùng nên trở nên "mang tính kỹ thuật hơn"
    • Để hiểu khủng hoảng phần mềm, cần hiểu các đường cong "mức độ thành thạo nền tảng" và "chu kỳ tăng trưởng/phát hành"
    • Bài viết này không phải clickbait, mà phản ánh hoàn cảnh với tư cách là một lập trình viên
    • Muốn đưa ra một phần lời giải cho vấn đề và đang lên kế hoạch cho bài viết tiếp theo
  • Khủng hoảng phần mềm

    • Bao gồm các vấn đề như vượt ngân sách dự án, trễ tiến độ, phần mềm kém hiệu quả, chất lượng thấp, không đáp ứng yêu cầu, khó bảo trì, hoặc không bàn giao được phần mềm
    • Phần mềm thành công thì bị bỏ qua, còn thất bại và lỗi mới được chú ý
    • Để máy tính đến được màn hình desktop, nó phải đi qua hàng trăm lớp trừu tượng, và điều này diễn ra hàng chục tỷ lần mỗi ngày trên toàn thế giới
  • Phát triển phần mềm và lãnh đạo

    • Ban lãnh đạo trong các công ty ô tô nhấn mạnh kiến thức kỹ thuật, nhưng trong phát triển phần mềm agile, năng lực kỹ thuật dừng lại ở các tầng thấp hơn
    • Lập trình viên phần mềm làm việc theo từng ticket mà không có cân nhắc mang tính triết học, và không được thăng tiến lên các vai trò lãnh đạo
    • Nhận thức về khủng hoảng phần mềm có khả năng chỉ bị giới hạn trong phạm vi sở thích cá nhân
  • Sự cần thiết của trừu tượng hóa

    • Trừu tượng hóa là công cụ thiết yếu, và vấn đề nằm ở trừu tượng hóa tệ hoặc quá nhiều trừu tượng hóa
    • Việc phát triển phần mềm đã trở nên dễ hơn và cũng được tài liệu hóa tốt
  • Công cụ và thông tin

    • Nếu biết đúng công cụ, việc phát triển phần mềm sẽ rất dễ
    • Phần lớn công cụ mà mọi người biết đến đều không tốt, và chịu ảnh hưởng lớn từ tư bản
    • Ví dụ, đã làm một video xây dựng ứng dụng marketplace phức tạp trong môi trường serverless chỉ trong 3 giờ, nhưng có rất ít lượt xem
  • GUI và khả năng kết hợp

    • Khi sử dụng các công cụ UNIX, người ta có được trải nghiệm nông và có thể kết hợp được
    • GUI không giao tiếp với nhau và không có khả năng kết hợp
    • Đang thử nghiệm các công cụ kết hợp GUI với shell pipeline
  • Tầm quan trọng của phần mềm

    • Phần lớn phần mềm không mang tính sống còn, nên ngay cả khi chất lượng thấp cũng không gây vấn đề quá lớn
    • Hầu hết lập trình viên phần mềm làm việc mà không có động lực như ở Silicon Valley
  • Tính mô-đun và trừu tượng hóa

    • Các hệ thống phức tạp như Internet được duy trì nhờ các lớp trừu tượng hóa phân tầng
    • Công cụ phần mềm đã được cải thiện đáng kể kể từ thập niên 70
    • Ví dụ, khi dùng copilot của VSCode, có thể tự động hoàn thành cả một API
  • Khủng hoảng quản lý dự án

    • Thay vì khủng hoảng phần mềm, thực ra tồn tại một cuộc khủng hoảng quản lý dự án
    • Có khoảng cách giữa người lập kế hoạch và người chịu trách nhiệm bàn giao
    • Việc thương mại hóa phát triển phần mềm khiến những người ở nhiều trình độ khác nhau đều có thể tham gia
    • Điều này tương tự ngành thực phẩm, và người ta không gọi đó là khủng hoảng nhà hàng