Lập trình thực chất là Xây dựng Lý thuyết: Một góc nhìn thay đổi tư duy
Bài viết phân tích tiểu luận kinh điển của Peter Naur, lập luận rằng lập trình không chỉ là viết mã mà là quá trình xây dựng một mô hình tư duy (lý thuyết) về vấn đề. Hiểu rõ "lý thuyết" này là chìa khóa để tạo ra phần mềm dễ bảo trì và phát triển bền vững.

Lập trình thực chất là Xây dựng Lý thuyết: Một góc nhìn thay đổi tư duy
Khi đọc xong bài viết "Programming as Theory Building" (Lập trình là Xây dựng Lý thuyết) của Peter Naur, suy nghĩ đầu tiên của tôi là: "Tại sao không ai bảo tôi phải đọc bài này sớm hơn?". Tôi đã đọc đi đọc lại nó nhiều lần khi cố gắng tổng hợp lại suy nghĩ về lý do tại sao quan điểm này lại hợp lý đến vậy.
Có bao giờ bạn gặp tình huống đang cố giải thích một điều gì đó, bạn tìm kiếm một từ ngữ hoặc thuật ngữ phù hợp, nhưng dù có tìm thế nào cũng không thể tìm ra? Tôi nghĩ rằng thuật ngữ "lý thuyết" của Naur chính là từ khóa còn thiếu khi nói đến việc viết mã tốt và tạo ra phần mềm dễ bảo trì. Tôi đã có nhiều ý tưởng và suy nghĩ về các chủ đề này, nhưng chúng là những khái niệm rời rạc. Khi xem lập trình là "xây dựng lý thuyết" theo cách Naur đề xuất, mọi thứ dường như khớp vào nhau, trả lời cho câu hỏi "tại sao viết phần mềm tốt lại khó khăn?".
Lập trình là xây dựng Lý thuyết
Tóm lại, "Programming as Theory Building" gợi ý rằng mã nguồn chương trình, tài liệu và các sản phẩm khác chỉ là thứ yếu so với bản chất thực sự của lập trình: Xây dựng sự hiểu biết, hay một mô hình tinh thần (mental model), về chương trình, các yêu cầu của nó và cách chúng liên quan đến mọi thứ xung quanh. Nghĩa là, mục tiêu chính của bạn với tư cách là một lập trình viên là học hỏi, hiểu rõ, ghi nhớ, cải thiện và chia sẻ "lý thuyết" này về chương trình.
Lý thuyết ảnh hưởng đến mã nguồn
Nếu nghĩ về những thứ như "mã tốt" hay "mã dễ bảo trì", điều gì xuất hiện trong đầu bạn? Có lẽ đó là những thứ giúp mã dễ hiểu hơn, như tuân thủ các quy ước tốt, viết mã "sạch", có kiến trúc tốt, v.v. Bạn cũng có thể nghĩ đến tài liệu và sơ đồ. Có thể là cả các bài kiểm tra tự động (automated tests).
Thống nhất các hoạt động phát triển
Nếu suy nghĩ kỹ, mục tiêu của mọi thứ liên quan đến việc viết mã dễ bảo trì thực chất là về việc truyền đạt ý định thiết kế của mã. Bạn viết mã sạch vì nó dễ hiểu chức năng, bạn kiến trúc mã để dễ hiểu cấu trúc và mục đích, bạn thêm tài liệu để giải thích mã, và vẽ sơ đồ vì mục đích tương tự. Tuy nhiên, ít nhất là theo kinh nghiệm của tôi, các nhà phát triển thường coi các khía cạnh khác nhau này là các hoạt động riêng biệt — ví dụ: viết kiểm thử là một hoạt động riêng với mục tiêu riêng, viết tài liệu là một hoạt động khác, v.v.
Nếu bạn nhìn nhận lập trình là xây dựng lý thuyết theo cách Naur gợi ý, bạn có thể thấy các hoạt động này là một phần của một chỉnh thể lớn hơn: Truyền đạt lý thuyết của chương trình. Khi được nhìn như một phần của chỉnh thể lớn hơn, bạn có thể bắt đầu sử dụng các hoạt động riêng lẻ để đạt được mục tiêu chung tốt hơn.
Tầm quan trọng của lý thuyết
Việc truyền đạt lý thuyết của chương trình là rất quan trọng: Nếu bạn cố gắng sửa đổi một chương trình mà không có sự hiểu biết về lý thuyết, bạn sẽ không thể làm điều đó một cách trơn tru mà không tạo ra các bản vá lỗi (hacky). Tương tự, nếu bạn cần đánh giá tính khả thi của một số thay đổi đối với mã, chẳng hạn như một tính năng mới, bạn không thể làm điều đó trừ khi bạn hiểu lý thuyết.
Theo nghĩa này, lập trình là xây dựng lý thuyết.
Nếu bạn nghĩ theo cách này, đột nhiên nhiều thứ khác lại kết nối với nhau. Ví dụ, Design patterns (Mẫu thiết kế) và Domain-Driven Design (DDD) có điểm chung gì? Chúng giúp bạn truyền đạt các ý tưởng và mô hình tinh thần được sử dụng trong mã của bạn — tức là chúng giúp truyền đạt lý thuyết của chương trình. Tương tự, những người khác đã đề xuất các khái niệm như "Kiểm soát trí tuệ" (Intellectual Control) — có một mô hình tinh thần về chương trình, cho phép bạn xác nhận nó hoạt động đúng và suy luận về các thay đổi — điều này cũng có thể được coi là một hình thức của "xây dựng lý thuyết".
Hy vọng tôi đã truyền đạt được ít nhất một phần giá trị của việc đọc tiểu luận của Peter Naur. Còn nhiều điều hơn thế nữa, vì vậy tôi rất khuyến khích bạn đọc văn bản gốc "Programming as Theory Building". Nó không quá dài và bạn có thể tìm thấy nó khá dễ dàng trên Google. Nếu bạn đã đọc nó, tôi rất muốn nghe suy nghĩ của bạn.
Bài viết liên quan

Công nghệ
Cerebras, đối tác thân thiết của OpenAI, sẵn sàng cho đợt IPO kỷ lục định giá tới 26,6 tỷ USD
04 tháng 5, 2026

Công nghệ
Microsoft giới thiệu Surface Pro 12 và Surface Laptop 8: Sức mạnh chip Intel, giá thành gây sốc
19 tháng 5, 2026
Công nghệ
Trang web ngăn chặn tự tử tại Hà Lan bị phát hiện chia sẻ dữ liệu người dùng cho các công ty công nghệ
13 tháng 5, 2026
