Một bài viết châm biếm về việc tránh lập trình hàm tại nơi làm việc đã khơi mào một cuộc thảo luận sôi nổi giữa các nhà phát triển về điều gì thực sự khiến code trở nên khó hiểu. Bài viết gốc mô tả một cách hài hước về tình huống một người quản lý cấm lập trình hàm sau khi nhận được phжалобы từ các thành viên trong nhóm, nhưng phản hồi từ cộng đồng lại tiết lộ những hiểu biết sâu sắc hơn về khả năng đọc code và động lực nhóm.
Method Chaining so với Lập trình hàm thực sự
Cuộc thảo luận nhanh chóng tập trung vào việc liệu method chaining có nên được coi là lập trình hàm hay không. Nhiều nhà phát triển chỉ ra rằng sự nhầm lẫn xuất phát từ việc trộn lẫn các khái niệm lập trình khác nhau. Method chaining, mặc dù tương tự như phong cách applicative của lập trình hàm, chỉ là syntax sugar giúp code trông gọn gàng hơn. Vấn đề thực sự không phải là bản thân lập trình hàm, mà là những chuỗi thao tác quá dài có thể khiến code khó theo dõi hơn.
Một số nhà phát triển lập luận rằng một vòng lặp for đơn giản với các thao tác rõ ràng bên trong thân vòng lặp có thể dễ đọc hơn nhiều so với các method chain phức tạp. Điều này làm nổi bật cách lựa chọn phong cách lập trình nên phụ thuộc vào tình huống cụ thể và sở thích của nhóm.
Các Yếu Tố Phức Tạp Phổ Biến Trong Lập Trình Hàm:
- Hệ thống suy luận kiểu toàn cục
- Cú pháp ngầm định (không có dấu ngoặc, dấu chấm phẩy)
- Currying và phong cách point-free
- Các biểu thức lồng nhau sâu
- Method chaining so với các vòng lặp đơn giản
Các lựa chọn thiết kế ngôn ngữ tạo ra độ phức tạp
Cuộc trò chuyện tiết lộ rằng các ngôn ngữ lập trình hàm thường đi kèm với những tính năng khiến chúng khó học. Bao gồm global type inference, cú pháp ngầm định loại bỏ dấu ngoặc và dấu chấm phẩy, currying, và lập trình theo phong cách point-free. Các biểu thức lồng nhau sâu nơi giá trị thực tế có thể cách xa hàng trăm dòng so với khai báo của nó cũng góp phần gây nhầm lẫn.
Nếu đoạn code này quá phức tạp đối với bạn thì bạn nên xem xét lại sự nghiệp của mình.
Thú vị là Rust được khen ngợi vì tránh được nhiều bẫy phức tạp này trong khi vẫn hỗ trợ các khái niệm lập trình hàm. Điều này cho thấy rằng khó khăn không phải vốn có của lập trình hàm mà là cách nó được triển khai trong các ngôn ngữ khác nhau.
Các ngôn ngữ được đề cập trong cuộc thảo luận:
- Scala: Được mô tả là ngôn ngữ thích hợp với độ phức tạp FP
- Kotlin: Được đặc trưng là " Java tốt hơn một chút"
- Rust: Được khen ngợi vì tránh được các bẫy phức tạp của FP
- JavaScript: Được tham chiếu cho cuộc tranh luận về promises và monads
Động lực nhóm và việc áp dụng công nghệ
Một số nhà phát triển có kinh nghiệm đã chia sẻ những hiểu biết về việc quản lý xung đột trong nhóm về phong cách lập trình. Cuộc thảo luận làm nổi bật cách lựa chọn các ngôn ngữ thích hợp như Scala đòi hỏi đào tạo và hỗ trợ nhóm phù hợp thay vì hạn chế các nhà phát triển có kinh nghiệm. Khi các nhóm áp dụng công nghệ tiên tiến, họ cần đầu tư vào giáo dục và lập trình cặp đôi để nâng cao trình độ cho mọi người.
Cuộc trò chuyện cũng đề cập đến bản chất mong manh của các nhóm kỹ sư phần mềm, nơi xung đột cái tôi có thể dẫn đến việc từ bỏ các kiến trúc trưởng thành để chuyển sang các giải pháp đơn giản hơn nhưng kém hiệu quả hơn. Mô hình này dường như đang trở nên phổ biến hơn khi ngành công nghiệp phát triển và các nhóm trở nên đa dạng hơn về trình độ kỹ năng.
Cuộc tranh luận cuối cùng cho thấy rằng các vấn đề về khả năng đọc code thường liên quan đến giao tiếp, đào tạo và quản lý nhóm hơn là bản thân paradigm lập trình. Các nhóm thành công tìm cách cân bằng giữa các kỹ thuật tiên tiến với code có thể bảo trì mà mọi người đều có thể hiểu và đóng góp.
Tham khảo: How to stop functional programming