Với 2 lĩnh vực yêu thích trước: Hệ điều hành và ngôn ngữ lập trình, tất cả chỉ dừng lại ở mức sở thích mà thôi, những gì tôi đã làm chỉ là các dự án nhỏ, hoặc là một phần nhỏ của các dự án khác. Trong tương lai tôi cũng chưa có ý tưởng gì về chúng xa hơn một đam mê cá nhân, vì thực sự cả 2 đều là những lĩnh vực khó và đòi hỏi một nguồn lực rất lớn.
Tuy nhiên, lĩnh vực thứ 3 này lại hoàn toàn khác, tôi phải làm việc với chúng hàng ngày: nhận các yêu cầu từ product manager rồi thảo luận với họ xem nên làm thế nào, đưa ra các phương án hoặc đánh giá các phương án từ đồng nghiệp khác, việc đánh giá này không chỉ đòi hỏi bạn biết về kỹ thuật, mà còn bắt buộc bạn phải nắm trong tay thông tin về nguồn lực, văn hóa doanh nghiệp hay nhiều yếu tố phi kỹ thuật khác. Chỉ sau khi chọn phương án, chúng tôi mới bắt đầu thiết kế ra ứng dụng và mới bắt tay vào code.Từ những ngày đầu tiên đi học, tôi đã luôn suy nghĩ về câu hỏi: Từ những yêu cầu đầu vào cho trước, làm thế nào để biết được ta cần tạo nên các lớp nào, đối tượng nào? Làm thế nào để từ một bài toán rất mơ hồ lại có thể tạo nên được một ứng dụng đáp ứng được yêu cầu người dùng, và còn phải:
Nâng cấp và bảo trì dễ dàng: nếu bạn không biết thế nào là nâng cấp và bảo trì dễ dàng, hãy thử đặt ra tình huống toàn bộ nhân sự trong dự án nghỉ việc, và bạn chỉ có một khoảng thời gian ngắn để chuyển giao cho nhóm mới. Khả năng chuyển giao càng lớn và càng mất ít thời gian, đồng nghĩa với ứng dụng của bạn càng dễ bảo trì. Còn nếu người tiếp nhận dự án thốt lên một câu: “Cái này thà đập đi làm lại từ đầu còn dễ hơn” (câu này quen quá 
) thì hẳn nó quá khó để chuyển giao.
Thỏa mãn các ràng buộc về tài nguyên và thời gian: nếu bạn có tài nguyên và thời gian vô hạn thì chẳng còn gì phải bàn.Tôi không nhớ đã đọc bao nhiêu cuốn sách, nhưng sau khi đọc rất nhiều, tôi nhận ra một điều: “Đọc sách không bao giờ đủ”. Bởi các tình huống và yêu cầu có trong thực tế vô cùng phong phú, việc bạn thiết kế ra một ứng dụng “tuyệt vời” nhưng vẫn bị chê là bình thường, bởi người dùng chỉ thích làm theo cách của họ, và dù muốn dù không bạn sẽ phải chỉnh sửa lại. Do vậy đối với tôi, một thiết kế cho phép thay đổi dễ dàng nhất luôn là một thiết kế tốt nhất.Vậy làm sao để “nâng cao tay nghề”? Hãy bắt tay vào làm các ứng dụng thực tế. Nghĩ ra đầu bài mà làm, và đưa ra các ràng buộc thật cao. Một cửa hàng bán sách trực tuyến (nghe quen quá), nhưng:
Làm thế nào để cho phép chạy trên nhiều máy chủ đồng thời?
Làm thế nào để phân tán các yêu cầu đến các máy chủ đó? Làm thế nào để đảm bảo tính toàn vẹn dữ liệu khi chúng được xử lý bởi các máy tính độc lập?
Làm thế nào để xác thực người dùng khi các request có thể được gửi đến các máy khác nhau?
Làm thế nào để tối ưu lại các tác vụ? Giúp cho các tác vụ quan trọng được thực hiện trước.
Làm thế nào để kết nối đến các đối tác xuất bản, giao nhận… vốn sử dụng các hệ thống quản lý khác nhau?
Làm thế nào để thay đổi hoặc thêm mới các chính sách, phương thức giao hàng, phương thức thanh toán mà không làm ảnh hưởng đến các thành phần khác?
Làm thể nào để tăng/giảm tải dễ dàng nhất khi triển khai các chiến dịch bán hàng theo thời vụ?…Bạn hãy xây dựng một ứng dụng với các câu hỏi trên trong đầu, khi đó bạn sẽ biết mình thiếu gì, và sẽ phải học thêm cái gì. Rõ ràng cùng một bài toán, nhưng khi lên tới quy mô lớn, nó đã hoàn toàn khác, và mỗi quyết định của bạn có thể ảnh hưởng rất lớn sau này.
Đọc sách rất tốt, nhưng thiếu đi một yếu tố thôi thúc bạn tìm hiểu (khi giải bài toán của mình), bạn sẽ chỉ đọc mà không thể nhớ gì cả.
Hi vọng một lúc nào đó tôi có thể nói sâu hơn về lĩnh vực này, tôi luôn ước gì mình có thể đem hết kiến thức kinh nghiệm đã có được trong hai mấy năm đi làm để chia sẻ lại, giúp các bạn có thể tiết kiệm được rất nhiều thời gian và tránh được các vấp ngã. Có thể là mở 1 lớp nhỏ, hay stream, hoặc cùng ngồi cà phê (khi dịch qua và tôi có thể về Việt Nam)… chắc sẽ vui lắm nhỉ!
Đào Hải Nam 