04 thg 6, 2025·4 phút
Tại sao các ý tưởng lập trình hàm liên tục quay lại trong mã hiện đại
Các ý tưởng hàm như bất biến, hàm thuần và map/filter liên tục xuất hiện trong các ngôn ngữ phổ thông. Tìm hiểu vì sao chúng hữu ích và khi nào nên dùng.
Các ý tưởng hàm như bất biến, hàm thuần và map/filter liên tục xuất hiện trong các ngôn ngữ phổ thông. Tìm hiểu vì sao chúng hữu ích và khi nào nên dùng.
“Các khái niệm lập trình hàm” đơn giản là những thói quen và tính năng ngôn ngữ xử lý tính toán như làm việc với giá trị, chứ không phải liên tục thay đổi trạng thái.
Thay vì viết mã kiểu “làm cái này, rồi thay đổi cái kia,” mã theo phong cách hàm thiên về “nhận đầu vào, trả về đầu ra.” Hàm của bạn càng hành xử như các phép biến đổi đáng tin cậy thì càng dễ dự đoán chương trình sẽ làm gì.
Khi người ta nói Java, Python, JavaScript, C#, hoặc Kotlin đang “hướng theo chức năng” hơn, không có nghĩa là những ngôn ngữ đó biến thành ngôn ngữ lập trình hoàn toàn hàm.
Ý họ là thiết kế ngôn ngữ phổ thông tiếp tục mượn những ý tưởng hữu ích—như lambda và hàm bậc cao—để bạn có thể viết một số phần của mã theo phong cách hàm khi có lợi, và vẫn dùng cách mệnh lệnh hoặc hướng đối tượng quen thuộc khi cách đó rõ ràng hơn.
Các ý tưởng hàm thường cải thiện khả năng bảo trì phần mềm bằng cách giảm trạng thái ẩn và làm hành vi dễ suy luận hơn. Chúng cũng có ích với đồng thời, vì trạng thái chia sẻ có thể thay đổi là nguồn chính gây ra race condition.
Những đánh đổi là có thực: trừu tượng thêm có thể cảm thấy lạ, bất biến đôi khi gây chi phí, và các tổ hợp “tinh quái” có thể làm giảm khả năng đọc nếu lạm dụng.
Đây là ý nghĩa của “các khái niệm hàm” xuyên suốt bài viết này:
Đây là công cụ thực dụng, không phải giáo điều—mục tiêu là dùng chúng nơi mã đơn giản và an toàn hơn.
Lập trình hàm không phải là xu hướng mới; đó là tập các ý tưởng quay lại mỗi khi phát triển mainstream gặp vấn đề mở rộng—hệ thống lớn hơn, đội ngũ lớn hơn, và phần cứng mới.
Cuối thập niên 1950 và 1960, các ngôn ngữ như Lisp coi hàm là giá trị thực sự mà bạn có thể truyền đi và trả về—điều chúng ta gọi nay là hàm bậc cao. Cùng thời kỳ đó cũng ra đời gốc rễ của ký hiệu “lambda”: cách gọn để mô tả hàm ẩn danh mà không cần đặt tên.
Trong thập niên 1970 và 1980, các ngôn ngữ hàm như ML và sau này Haskell thúc đẩy ý tưởng bất biến và thiết kế theo kiểu mạnh, chủ yếu trong môi trường học thuật và một số công nghiệp hẹp. Trong khi đó, nhiều ngôn ngữ “phổ thông” âm thầm mượn mảng, và các ngôn ngữ script đã phổ biến việc coi hàm như dữ liệu trước khi nền tảng doanh nghiệp bắt kịp.
Trong thập niên 2000 và 2010, các ý tưởng hàm trở nên khó bỏ qua:
Gần đây hơn, các ngôn ngữ như Kotlin, Swift và Rust củng cố công cụ thao tác collection theo hàm và mặc định an toàn hơn, trong khi nhiều framework khuyến khích pipeline và các biến đổi khai báo.
Những khái niệm này quay lại vì bối cảnh thay đổi. Khi chương trình nhỏ hơn và hầu hết chạy đơn luồng, “chỉ thay đổi biến” thường ổn. Khi hệ thống phân tán, đồng thời, và được bảo trì bởi nhiều người, chi phí của coupling ẩn tăng lên.
Các mẫu lập trình hàm—như lambda, pipeline collection, và luồng bất đồng bộ rõ ràng—thường làm cho phụ thuộc hiển nhiên và hành vi dễ dự đoán hơn. Các nhà thiết kế ngôn ngữ tiếp tục giới thiệu chúng vì đó là công cụ thực tế cho độ phức tạp hiện đại, chứ không phải cổ vật viện bảo tàng khoa học máy tính.
Mã có tính dự đoán hành xử giống nhau mỗi khi dùng trong cùng tình huống. Đó chính là thứ mất đi khi hàm phụ thuộc bí mật vào trạng thái ẩn, thời gian hiện tại, cài đặt toàn cục, hoặc bất cứ gì đã xảy ra trước đó trong chương trình.
Khi hành vi dự đoán được, gỡ lỗi ít giống thám tử và giống việc kiểm tra hơn: bạn có thể thu hẹp vấn đề tới một phần nhỏ, tái tạo nó, và sửa mà không lo nguyên nhân “thực sự” nằm ở nơi khác.
Phần lớn thời gian gỡ lỗi không phải gõ một sửa—mà là tìm hiểu mã thực sự đã làm gì. Các ý tưởng hàm đẩy bạn tới hành vi có thể suy luận cục bộ:
Điều đó dẫn đến ít lỗi kiểu “chỉ hỏng vào thứ Ba”, ít println rải khắp nơi, và ít sửa lỗi vô tình tạo bug mới hai màn hình sau đó.
Một hàm thuần (cùng input → cùng output, không side effect) thân thiện với unit test. Bạn không cần dựng môi trường phức tạp, mock nửa ứng dụng, hay reset trạng thái toàn cục giữa các lần chạy test. Bạn cũng có thể tái sử dụng nó khi refactor vì nó không giả định nơi nó được gọi.
Điều này quan trọng trong công việc thực tế:
Trước: Một hàm calculateTotal() đọc discountRate toàn cục, kiểm cờ “holiday mode” toàn cục, và cập nhật lastTotal toàn cục. Báo lỗi nói tổng “đôi khi sai.” Giờ bạn đang đi truy ngược trạng thái.
Sau: calculateTotal(items, discountRate, isHoliday) trả về một số và không thay đổi gì khác. Nếu tổng sai, bạn ghi lại đầu vào một lần và tái tạo vấn đề ngay lập tức.
Tính dự đoán là một trong những lý do chính khiến các tính năng lập trình hàm liên tục được thêm vào ngôn ngữ phổ thông: chúng làm công việc bảo trì hàng ngày bớt bất ngờ, mà bất ngờ mới là thứ làm phần mềm tốn kém.
“Hiệu ứng phụ” là bất cứ thứ gì đoạn mã làm ngoài việc tính toán và trả về giá trị. Nếu một hàm đọc hoặc thay đổi thứ gì bên ngoài đầu vào—tệp, cơ sở dữ liệu, thời gian hiện tại, biến toàn cục, gọi mạng—thì nó làm nhiều hơn là chỉ tính toán.
Ví dụ đời thường có ở khắp nơi: viết log, lưu đơn hàng vào DB, gửi email, cập nhật cache, đọc biến môi trường, hoặc sinh số ngẫu nhiên. Không có cái nào là “xấu”, nhưng chúng thay đổi thế giới xung quanh chương trình—và đó là nơi bắt đầu những điều bất ngờ.
Khi hiệu ứng trộn vào logic bình thường, hành vi không còn là “dữ liệu vào, dữ liệu ra.” Cùng đầu vào có thể cho kết quả khác tùy trạng thái ẩn (cái gì đã có trong DB, ai đang đăng nhập, feature flag, request mạng thất bại). Điều đó khiến lỗi khó tái tạo và sửa khó tin cậy hơn.
Nó cũng làm phức tạp việc gỡ lỗi. Nếu một hàm vừa tính chiết khấu vừa ghi DB, bạn không thể gọi nó hai lần khi điều tra—vì gọi hai lần có thể tạo hai bản ghi.
Lập trình hàm khuyến khích một tách biệt đơn giản:
Với tách này, bạn có thể test phần lớn mã mà không cần DB, không cần mock nửa thế giới, và không lo một phép tính “đơn giản” vô tình gây ghi.
Chế độ lỗi phổ biến nhất là “effect creep”: một hàm log “chút ít”, rồi nó đọc config, rồi ghi metric, rồi gọi service. Chẳng mấy chốc, nhiều phần codebase phụ thuộc vào hành vi ẩn.
Một quy tắc tốt: giữ các hàm cốt lõi nhàm chán—nhận inputs, trả outputs—và làm cho hiệu ứng phụ rõ ràng và dễ tìm.
Các khái niệm hàm là các thói quen và tính năng ngôn ngữ thực dụng giúp mã hoạt động giống như các phép biến đổi "input → output".
Nói ngắn gọn, chúng nhấn mạnh:
map, filter, và reduce để biến đổi dữ liệu rõ ràngKhông. Điểm mấu chốt là áp dụng mang tính thực dụng, chứ không phải theo tư tưởng.
Ngôn ngữ phổ thông vay mượn các tính năng (lambdas, streams/sequences, pattern matching, công cụ hỗ trợ bất biến) để bạn có thể dùng phong cách hàm khi hữu ích, đồng thời vẫn viết mã imperative hoặc OO khi rõ ràng hơn.
Bởi vì chúng giảm những điều bất ngờ.
Khi hàm không phụ thuộc vào trạng thái ẩn (biến toàn cục, thời gian hiện tại, đối tượng mutable), hành vi dễ tái tạo và lý giải hơn. Điều đó thường dẫn tới:
Một hàm thuần (pure function) trả về cùng một kết quả cho cùng một đầu vào và không có hiệu ứng phụ.
Điều này giúp việc test trở nên dễ dàng: bạn gọi hàm với các input biết trước và kiểm tra kết quả mà không cần dựng cơ sở dữ liệu, đồng hồ hệ thống, cờ toàn cục, hay các mock phức tạp. Hàm thuần cũng dễ tái sử dụng khi refactor vì ít phụ thuộc ngầm.
Hiệu ứng phụ là bất cứ điều gì hàm làm ngoài việc trả về một giá trị—đọc/ghi tệp, gọi API, ghi log, cập nhật cache, tác động biến toàn cục, dùng thời gian hiện tại, sinh số ngẫu nhiên, v.v.
Các hiệu ứng làm hành vi khó tái tạo. Cách thực dụng là:
Bất biến nghĩa là bạn không thay đổi một giá trị tại chỗ; bạn tạo phiên bản mới thay vào đó.
Điều này giảm lỗi do trạng thái chia sẻ có thể thay đổi, đặc biệt khi dữ liệu được truyền đi nhiều nơi hoặc dùng đồng thời. Nó cũng làm cho caching hay undo/redo tự nhiên hơn vì các phiên bản cũ vẫn tồn tại.
Có—đôi khi.
Chi phí thường xuất hiện khi bạn sao chép nhiều cấu trúc lớn trong vòng lặp chặt. Các thỏa hiệp thực tế gồm:
Chúng thay thế boilerplate vòng lặp lặp đi lặp lại bằng các phép biến đổi có thể tái sử dụng và đọc được.
map: biến đổi từng phần tửfilter: giữ phần tử thỏa điều kiệnreduce: gộp nhiều giá trị thành mộtDùng đúng, các pipeline này làm ý định rõ ràng (ví dụ: “đơn đã thanh toán → số tiền → tổng”) và giảm các biến thể vòng lặp copy-paste.
Bởi vì lỗi đồng thời thường đến từ trạng thái chia sẻ có thể thay đổi.
Nếu dữ liệu bất biến và các phép biến đổi là thuần, các tác vụ có thể chạy song song an toàn hơn với ít khóa và ít điều kiện race hơn. Điều đó không đảm bảo tăng tốc, nhưng thường cải thiện độ đúng đắn khi chịu tải.
Bắt đầu từ những bước nhỏ, ít rủi ro:
Dừng lại và đơn giản hóa nếu mã trở nên quá tinh vi—đặt tên bước trung gian, trích xuất hàm, và ưu tiên tính dễ đọc hơn các cấu trúc dày đặc.