Lịch Sử Phần Mềm: Cuộc Chiến Bất Tận Chống Lại Độ Phức Tạp

Có một pattern ẩn sau mỗi chương lớn trong lịch sử software engineering — một pattern chỉ hiện ra rõ ràng khi bạn nhìn đủ xa.

Mọi tool, mọi paradigm shift, mọi công nghệ "cách mạng" đều quy về cùng một nước cờ căn bản: nâng tầng abstraction lên để developer tốn ít thời gian hơn vào việc nói chuyện với máy móc và tập trung hơn vào việc giải quyết vấn đề thực sự.

Chỉ vậy thôi. Toàn bộ câu chuyện là ở đó.

Bạn Sẽ Học Được Gì

✅ Ba cuộc dịch chuyển abstraction lớn trong lịch sử phần mềm
✅ Tại sao mỗi cuộc dịch chuyển đều bị thế hệ trước kháng cự
✅ Pattern từ machine code đến AI cho bạn thấy gì về tương lai
✅ Tại sao architectural thinking quan trọng hơn bao giờ hết khi abstraction ngày càng dày

Insight Cốt Lõi: Abstraction Chính Là Tiến Bộ

Trước khi truy theo hành trình này, hãy nói rõ abstraction thực sự làm gì.

Khi bạn viết user.save() thay vì tự viết raw SQL, bạn không phải đang lười biếng — bạn đang làm việc ở tầng của problem, không phải tầng của machine. Khi bạn deploy lên cloud platform thay vì tự rack server, bạn không đang né tránh trách nhiệm — bạn đang chuyển sự chú ý từ logistics hạ tầng sang system design.

Abstraction là cơ chế giúp cả ngành nâng nền năng suất của mình lên.

Mỗi thế hệ tooling là một lời lập luận rằng thế hệ trước đang tiêu tốn quá nhiều sự chú ý vào những thứ sai.

Dịch Chuyển 1: Từ Nói Chuyện Với Máy Sang Nói Chuyện Với Người

Hành trình: Machine Code → Assembly → Ngôn ngữ bậc cao → AI

Thời kỳ đầu, lập trình có nghĩa là hiểu tường tận cái máy vật lý. Bạn tự nạp register bằng tay. Bạn tính địa chỉ bộ nhớ. Bạn nghĩ theo từng byte.

Assembly là bước nhảy đầu tiên: đặt tên dễ đọc cho các câu lệnh. Vẫn còn gần với phần cứng, nhưng ít ra bạn có thể đọc lại vào sáng hôm sau.

Ngôn ngữ bậc cao — FORTRAN, COBOL, C, rồi Java, Python — là bước nhảy thứ hai. Quản lý memory tự động hơn (hoặc ít nhất an toàn hơn). Diễn đạt logic bằng các construct gần với cách con người suy nghĩ, không phải cách CPU thực thi.

Mỗi bước đều vấp phải sự kháng cự từ thế hệ trên:

"Lập trình viên thực sự viết assembly."

"Nếu không hiểu pointer thì không hiểu lập trình."

"Những abstraction bậc cao này chỉ là bánh xe phụ cho người không thể code."

Và giờ đây, AI code generation là bước nhảy thứ ba — từ viết syntax sang mô tả intent bằng ngôn ngữ tự nhiên. Sự kháng cự nghe quen thuộc:

"Nếu không tự viết thì không hiểu gì cả."

Pattern không thay đổi. Mỗi thế hệ đều bảo vệ tầng abstraction mà họ đã master như là tầng "thực sự".

Điều thực sự thay đổi: developer không còn quản lý register nữa mà quản lý architecture. Machine ngày càng ít hiển thị; solution ngày càng hiển thị hơn.

Dịch Chuyển 2: Từ Lưu Dữ Liệu Sang Quản Trị Thông Tin

Hành trình: File I/O bare-metal → DBMS → Raw SQL → ORM

Các chương trình thời đầu tự quản lý dữ liệu trực tiếp: mở file, tìm đến một byte offset cụ thể, đọc raw bytes. Storage là một vấn đề low-level được nhúng xuyên suốt application logic.

Database management systems tách biệt việc tổ chức dữ liệu ra khỏi application code. Giờ đây có một hệ thống riêng xử lý persistence, indexing và concurrency — bạn chỉ cần query nó.

SQL là abstraction trên storage engine vật lý. Bạn mô tả cái bạn muốn, không phải cách lấy nó. Query planner tự xử lý phần còn lại.

ORM đẩy thêm một tầng: mô tả domain của bạn theo objects — User, Order, Product — và để ORM dịch sang SQL. Datastore trở thành một implementation detail.

Trade-off ở mỗi tầng đều giống nhau: bạn từ bỏ quyền kiểm soát chi tiết, đổi lấy khả năng suy nghĩ ở tầng cao hơn. Developer dùng ORM có thể ship feature trong một buổi chiều — công việc mà trước đây mất vài ngày viết raw SQL thủ công.

Chỉ trích cũng luôn giống nhau: "Nhưng N+1 problem thì sao? Performance thì sao?"

Những lo ngại chính đáng. Nhưng đều giải quyết được ở tầng ORM — và developer hiểu cả abstraction lẫn những gì bên dưới nó mới là người đưa ra quyết định đó đúng đắn.

Dịch Chuyển 3: Từ Nuôi Server Sang Vận Hành Solution

Hành trình: On-premise hardware → VM → Cloud → Serverless / PaaS

Ngày xưa, "deploy software" có nghĩa là đặt phần cứng vào một căn phòng mà bạn chịu trách nhiệm — điều hòa, điện, cáp, capacity planning, bảo mật vật lý.

Virtualization là bước nhảy đầu tiên: machine vật lý trở thành một lớp trừu tượng. Một server, nhiều environment.

Cloud là bước nhảy thứ hai: data center trở thành vấn đề của người khác. Bạn provision resource qua API thay vì purchase order.

Infrastructure-as-Code là bước nhảy thứ ba: toàn bộ environment của bạn trở thành một version-controlled config file. Một region mới, một replica mới, disaster recovery setup — tất cả chỉ là terraform apply.

Serverless và PaaS đẩy tiếp: bạn mô tả một function hay container, và platform lo scaling, availability, cold start. Developer từng lo nhiệt độ phòng server giờ scale lên triệu user chỉ với vài dòng config.

Vấn Đề Rò Rỉ

Đây là sự thật khó chịu đi kèm với mỗi lần được abstraction.

Abstraction càng cao, bạn càng có thể làm được nhiều thứ mà không cần hiểu những gì bên dưới. Đó là mục đích. Nhưng abstraction bị rò rỉ — chúng thất bại theo những cách chỉ có nghĩa khi bạn hiểu tầng bên dưới.

Một ORM sinh ra cartesian product vì bạn quên specify join condition. Một serverless function cold-start 3 giây dưới tải vì bạn không hiểu execution model. Một cloud deployment tốn gấp mười lần dự kiến vì autoscaling không được giới hạn.

Developer chỉ biết abstraction sẽ đâm vào tường ngay khi nó rò rỉ. Developer hiểu cả hai tầng thì điều hướng qua failure, sửa config, và giải thích cho team tại sao chuyện đó xảy ra.

Đây là ý nghĩa thực tế của architectural thinking: không phải bạn phải làm việc ở mọi tầng cùng lúc, mà là bạn hiểu tầng nào một problem tồn tại ở đó, và các tầng tương tác với nhau như thế nào.

AI Nằm Ở Đâu Trong Câu Chuyện Này

AI code generation là bước abstraction táo bạo nhất mà ngành đã thực hiện. Bạn mô tả ý định bằng ngôn ngữ tự nhiên, và tool tạo ra code chạy được.

Điều này sẽ kéo chi phí viết phần mềm xuống rất nhiều. Pattern tương tự sẽ diễn ra: một làn sóng khả năng mới, sự kháng cự từ thế hệ đã master tầng trước đó, và cuối cùng là baseline mới của "lập trình" có nghĩa là gì.

Vấn đề abstraction bị rò rỉ không biến mất — nó trầm trọng hơn. Code do AI generate có thể sai theo những cách trông có vẻ đúng. Nó có thể tạo ra giải pháp chạy được nhưng vi phạm architecture của system đang được tích hợp vào. Nó có thể sinh ra security vulnerability vượt qua code review.

Giá trị của một engineer giỏi sẽ không còn ở khả năng tạo ra code — AI làm được điều đó. Giá trị sẽ ở khả năng đánh giá, tích hợp, và chịu trách nhiệm cho các solution được ship.

AI có thể viết code. Bạn là người thiết kế system.

Sợi Chỉ Đỏ Chạy Xuyên Suốt

Nhìn ba dịch chuyển cùng nhau:

Domain	Trước kia	Bây giờ
Ngôn ngữ	Quản lý register và memory	Mô tả intent bằng ngôn ngữ tự nhiên
Dữ liệu	Quản lý byte và file offset	Làm việc với domain object
Hạ tầng	Sở hữu và vận hành phần cứng	Cấu hình và deploy solution

Trong mỗi trường hợp, vấn đề low-level không biến mất — nó được đóng gói lại. Developer hiểu những gì được đóng gói thì làm việc hiệu quả hơn người không hiểu.

Bài học nhất quán xuyên suốt 70 năm lịch sử phần mềm: những engineer phát triển mạnh qua mỗi lần abstraction shift là những người học tầng mới nhanh và giữ được mental model về những gì bên dưới.

Không phải vì họ cần làm việc ở tầng thấp mỗi ngày. Mà vì họ hiểu tại sao abstraction đó tồn tại, chỗ nào nó rò rỉ, và làm thế nào để suy luận về system một cách tổng thể.

Điều Này Có Nghĩa Gì Với Career Của Bạn

Lần tới khi bạn nghe ai đó phủ nhận một tool là "không phải lập trình thực sự" — ngôn ngữ bậc cao, framework, cloud platform, AI assistant — hãy nhớ lại pattern này.

Mỗi thế hệ đều đưa ra lập luận này. Mỗi thế hệ đều đúng một phần (abstraction có che giấu complexity) và sai nhiều hơn (che giấu complexity chính là mục đích).

Câu hỏi thực chất không phải là liệu một abstraction mới có phải là "công việc thực sự" không. Mà là:

Abstraction này cho phép tôi ngừng nghĩ về điều gì?
Nó rò rỉ ở đâu, và tôi cần hiểu gì khi điều đó xảy ra?
Nó thay đổi chỗ nào mà khả năng phán đoán kiến trúc được áp dụng?

Lịch sử phần mềm không phải là câu chuyện về sự lười biếng. Đó là câu chuyện về ngành nghề này chuyển hướng sự chú ý của con người một cách có hệ thống — từ máy móc sang vấn đề thực sự.

Chương tiếp theo đang được viết. Những engineer hiểu được hành trình này là những người góp phần viết nó.

Tags: software-engineering · career · opinion · architecture · history