NỘI DUNG BÀI VIẾT
Từ khi ra đời Java đã trở thành một ứng cử viên thay thế cho COBOL để xây dựng các hệ thống Enterprise và người ta bắt đầu đặt câu hỏi “Khi nào COBOL sẽ chết?”. 20 năm sau, rất nhiều ngôn ngữ khác ra đời dựa trên nền tảng JVM và người ta (lại) bắt đầu đặt câu hỏi “Khi nào Java chết?”, có lẽ phải chờ COBOL chết trước!
Nếu bạn lượn lờ các website nổi tiếng về technical như Medium, Quora, Reddit, DZone, CodeProject … sẽ thấy rất nhiều debate như vậy. Một chủ đề cũng rất phổ biến là ưu nhược điểm của Java khi so sánh với các ngôn ngữ khác, các bài viết và tranh luận khá chi tiết, các bạn quan tâm có thể Googling. Nhưng đối với tôi các bài viết đó đều viết cho đối tượng là Lập trình viên mới học (Junior developer), đối với Senior developer thì “nhạc nào cũng nhảy” chả liên quan đến ngôn ngữ nữa. Vì vậy tôi viết article này dưới góc nhìn của một Software Architect với 15 năm kinh nghiệm.
1. Hoạt động trên JVM
Java không phải là một ngôn ngữ tốt, nếu so sánh về tính năng thì thua kém rất nhiều ngôn ngữ khác. Ưu điểm lớn nhất của Java có lẽ là một ngôn ngữ hoạt động trên JVM. Với 30 năm phát triển song song với Java (lossy couple nhờ ByteCode), JVM đã giới thiệu rất nhiều tính năng trở thành chuẩn mực như GC, Just-in-time compiler, Escape Analysis … Source code của Java khi compile sang ByteCode đã được optimize rất nhiều, sau đó khi JIT compile thành mã máy lại được optimize một lần nữa để phù hợp với từng CPU cụ thể tại run time.
Với JVM, một lập trình viên có kỹ năng không quá cao vẫn có thể xây dựng được các hệ thống chạy ổn định và hiệu năng cao. Một hệ thống tương tự nếu sử dụng C++ sẽ cần những lập trình viên rất nhiều kinh nghiệm và thời gian phát triển hệ thống có thể sẽ dài hơn.
2. Code chi tiết
Rất nhiều người chỉ trích Java có cú pháp thừa thãi khiến lập trình viên phải viết code dài hơn dẫn đến giảm hiệu quả làm việc. Điều đó hoàn toàn đúng và Java 10 giới thiệu keyword var để khai báo biến hoặc Java 8 với Streaming API có thể giúp code ngắn gọn hơn.
Nhưng nếu bạn làm việc với các hệ thống lớn thì sẽ suy nghĩ hoàn toàn khác: thời gian viết code rất ít so với thời gian phải đọc code và viết code thì dễ hơn maintain code rất nhiều. Cú pháp dài giúp code sáng sủa và dễ đọc, dễ maintain. Nếu bạn thích code ngắn gọn, xúc tích thì có thể chọn Python, nhưng có bạn dev nào đã thấy dự án dùng Python với vài nghìn file source code và hàng triệu dòng code chưa? Khi bạn phải làm việc với các hệ thống có size tương tự với hơn 10 năm phát triển thì sẽ thấy giá trị của những dòng code dài và dễ hiểu.
Fun fact: khi tôi mới học lập trình cũng rất ngưỡng mộ những dòng code mà mình đọc chả hiểu gì và cố gắng viết code sao cho càng ít càng tốt, nhưng càng về sau thì tôi càng cố viết đơn giản và dài dòng. Ở đây có thể trích dẫn 1 quote nổi tiếng của Martin Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
3. Các phiên bản Java tập trung vào sự tương thích
Các tính năng của Java được mô tả chi tiết trong các Java Specification Requests và được lựa chọn cho phiên bản mới một cách cẩn thận bởi một Hội đồng. Tiêu chí quan trọng nhất để lựa chọn chính là khả năng tương tích với các phiên bản trước đó của Java, ví dụ: ByteCode được biên dịch bởi Java 5 (version 49) từ năm 2004 có thể chạy được trên JVM version 52 (Java 8) hoặc JVM version 55 (Java 11). Tất nhiên không phải là tương thích 100%, nhưng Hội đồng đã làm rất tốt nhiệm vụ của mình và nếu có bug cũng được fix rất nhanh. Nhưng điều này có ý nghĩa gì?
Đầu tiên là các hệ thống cũ có thể nâng cấp lên JVM phiên bản mới (với tính năng mới, performance được cải tiến, fix bug …) rất dễ dàng mà không lo crash, đồng thời cũng không phải biên dịch lại mã nguồn và không phải tiến hành kiểm thử. Chi phí để kiểm thử các hệ thống lớn thường không nhỏ, các hệ thống liên quan đến tài chính, ngân hàng có thể mất tới 6 tháng hoặc 1 năm.
Đối với các hệ thống mới xây dựng có thể được đảm bảo một tương lai lâu dài, hệ thống có thể chạy ổn định 20 năm nữa mà không cần adapt với những phiên bản mới của JVM. Việc adapt tốn rất nhiều chi phí và rủi ro như sinh ra bug mới, effort để test lại. Ngoài ra còn có rủi ro không tương thích giữa các phiên bản của Framework, nếu bạn nào đã thử migrate code từ dotNET 1.0 lên 2.0 hoặc 3.0 sẽ rất thấu hiểu (một ví dụ điển hình khác là Python 2 lên Python 3).
Fun fact: Đối với nhiều developer thì tính năng mới tốt nhất của Java 8 là Streaming API, nhưng đối với tôi thì tính năng default function của Interface mới thực sự có nhiều ý nghĩa: các interface trong thư viện có thể thêm mới các method mà không ảnh hưởng đến code cũ đã được compile.
Kết luận
Số phận của một Enterprise system phụ thuộc vào rất nhiều yếu tố, lựa chọn đúng hệ sinh thái để phát triển là một yếu tố quan trọng. Java và JVM đã chứng minh được sự ổn định và sẽ còn chiếm tỷ trọng lớn trong tương lai xa.
Tham khảo khóa học lập trình web 6 tháng, đảm bảo 100% công việc đầu ra!
Nguồn: https://codelearn.io/sharing/la-mot-senior-developer-toi-chon-java
