Phân Biệt Coder và Software Engineer: Bẫy "Export 500k Dòng" và Sức Mạnh của Tư Duy "The WHY"

Trong ngành phát triển phần mềm, ranh giới giữa một lập trình viên (Coder) và một kỹ sư/người giải quyết vấn đề (Software Engineer/Problem Solver) thường không nằm ở việc ai viết code giỏi hơn, mà nằm ở câu hỏi họ đặt ra trước khi gõ dòng code đầu tiên.

Hãy cùng mổ xẻ một tình huống kinh điển mà 90% các dự án đều từng gặp phải để thấy sự khác biệt này.

1. Tình huống: "Hãy cho chị nút Export 500.000 đơn hàng ra Excel"

Một ngày đẹp trời, Product Manager (PM) giao cho bạn một ticket với yêu cầu: "Thêm chức năng export toàn bộ lịch sử đơn hàng (hơn 500.000 bản ghi) ra file Excel trên trang Admin Dashboard."

Nếu tiếp cận bằng tư duy The HOW (Tư duy của thợ code), não bộ của bạn sẽ lập tức nhảy số sang các vấn đề kỹ thuật:

• Làm sao để query 500k dòng mà không treo Database?
• Xử lý file Excel nặng thế nào để RAM không bị OOM (Out of Memory)?
• Chắc chắn phải dùng Stream! Phải đưa vào Message Queue (RabbitMQ/Redis) để chạy background job, rồi gửi email chứa link tải file khi xong!

Hậu quả: Bạn mất 3 đến 5 ngày hì hục thiết kế một hệ thống Queue phức tạp. Hệ thống thỉnh thoảng vẫn giật lag vì I/O quá nặng, tốn tài nguyên server. Và tệ nhất, bạn đã giải quyết xuất sắc một bài toán... không hề mang lại giá trị thực sự.

2. Cú lật ngược tình thế: Tư duy "The WHY" (Quyền làm chủ - Ownership)

Một Kỹ sư phần mềm có tư duy sản phẩm sẽ dừng lại và hỏi câu hỏi quan trọng nhất: "Tại sao user lại cần tải 500.000 dòng dữ liệu này về máy?"

Khi bạn đi hỏi bộ phận Kế toán, câu trả lời nhận được có thể khiến bạn ngã ngửa:

"À, hàng tháng tụi chị phải làm báo cáo. Do hệ thống không xem được tổng doanh thu tháng và top 50 khách hàng VIP, nên chị đành bảo PM làm nút tải hết về. Tải xong chị đưa vào Excel để kéo hàm VLOOKUP và Pivot Table."

Đây chính là hiện tượng The XY Problem nổi tiếng trong giới kỹ thuật:

1. Người dùng có vấn đề X (Cần xem tổng doanh thu và top khách hàng).
2. Họ tự nghĩ ra giải pháp Y (Tải 500k dòng về để tự tính Excel).
3. Họ yêu cầu bạn làm Y.

Nếu bạn nhắm mắt làm Y, bạn thất bại. Việc của bạn là phải tìm ra X.

3. Giải pháp "Win-Win": Ít Code Hơn, Giá Trị Cao Hơn

Khi đã nắm được "The WHY" (Vấn đề X), giải pháp thực sự trở nên vô cùng đơn giản:

• Về phía kỹ thuật: Không cần Queue, không cần Background Job. Bạn chỉ mất nửa ngày để viết 2 câu query SQL GROUP BY gom nhóm doanh thu theo tháng và ORDER BY lọc top 50 khách hàng, sau đó đẩy ra một màn hình "Báo Cáo" đơn giản.
• Về phía người dùng: Thay vì phải chờ đợi tải file nặng nề, lạch cạch ngồi kéo Excel có nguy cơ sai số, giờ đây Kế toán chỉ cần một cú click chuột là có ngay báo cáo trong chưa tới 1 giây. Trải nghiệm được nâng lên mức "Wow".

Một giải pháp xuất sắc không phải là một hệ thống chằng chịt các công nghệ phức tạp, mà là giải pháp dùng ít tài nguyên nhất để giải quyết triệt để nhất nỗi đau của người dùng.

4. Bỏ túi 3 nguyên tắc nhận diện "Cờ Đỏ" (Red Flags)

Để không bao giờ rơi vào bẫy làm theo yêu cầu một cách máy móc, hãy ghi nhớ các dấu hiệu sau khi nhận ticket:

1. Dấu hiệu "Quá khổ": Bất kỳ yêu cầu nào đòi hỏi hiển thị hoặc xuất hàng chục, hàng trăm ngàn dòng dữ liệu thô. Mắt người không thể đọc hết lượng data đó, chắc chắn họ đang muốn dùng nó để tính toán tiếp ở một phần mềm khác.
2. Dấu hiệu "Cứ đưa hết đây": Khi người dùng nói "Cứ xuất hết ra, tôi sẽ tự lọc", điều đó chứng tỏ hệ thống của bạn đang thiếu các công cụ Filter/Aggregation mà họ thực sự cần.
3. Câu hỏi vàng của mọi Developer: Trước khi nhận task nặng, hãy hỏi PM/User:

   "Sau khi lấy được file/dữ liệu này, bước tiếp theo anh/chị sẽ thao tác gì với nó?"

💡 Kết luận

Code giỏi là một lợi thế, nhưng hiểu đúng vấn đề trước khi code mới là thứ định hình một Senior Engineer. Hãy ngừng việc làm một "thợ gõ" chỉ biết nhận spec, và bắt đầu trở thành một người đồng hành cùng sản phẩm.