Lập trình thời AI Bài 3: Chuyển dịch từ Coder sang Software Architect

1. Kim tự tháp giá trị ngành kỹ thuật phần mềm

Để không bị AI thay thế, bạn cần hiểu vị trí của mình nằm ở đâu trong thang giá trị:

        ┌────────────────────────────────┐
        │     1. ĐỊNH HÌNH BÀI TOÁN      │  (Con người độc quyền: Hiểu nghiệp vụ, đàm phán)
        ├────────────────────────────────┤
        │    2. THIẾT KẾ KIẾN TRÚC       │  (Con người quyết định: Trade-offs, Scalability)
        ├────────────────────────────────┤
        │    3. CHUYỂN ĐỔI LOGIC / CÚ PHÁP│ ◄── AI đang chiếm lĩnh hoàn toàn tầng này
        ├────────────────────────────────┤
        │     4. GÕ CODE & RUN THỬ       │
        └────────────────────────────────┘

• Tầng 3 & 4 (Coder): Nhận đầu vào rõ ràng và viết cú pháp. Đây là tầng có giá trị gia tăng thấp nhất và chi phí thay thế rẻ nhất.
• Tầng 1 & 2 (Software Architect): Phân rã bài toán lớn, lựa chọn công nghệ, thiết kế luồng dữ liệu và chịu trách nhiệm về tính toàn vẹn của hệ thống.

2. Ba trụ cột tư duy của một Kiến trúc sư phần mềm

Khi rời bỏ tư duy "thợ gõ", bạn phải rèn luyện 3 năng lực cốt lõi sau:

A. Tư duy phân rã hệ thống (System Decomposition)

• Biết cách bẻ nhỏ một hệ sinh thái phức tạp (ví dụ: sàn thương mại điện tử) thành các dịch vụ độc lập: Quản lý đơn hàng, Thanh toán, Kho vận, Thông báo.
• Thiết kế giao thức giao tiếp giữa các thành phần: Đồng bộ qua REST/gRPC hay Bất đồng bộ qua Message Queue (Kafka, RabbitMQ)?

B. Nghệ thuật đánh đổi (Architectural Trade-offs)

• AI không thể chọn hộ bạn giữa việc tối ưu tốc độ đọc (Read-heavy) hay tốc độ ghi (Write-heavy).
• Bạn phải tự quyết định: Dùng SQL (ACID, toàn vẹn dữ liệu) hay NoSQL (Mở rộng linh hoạt, độ trễ thấp)? Dùng Microservices để mở rộng đội ngũ hay dùng Monolith để phát triển nhanh ở giai đoạn đầu?

C. Khả năng chịu lỗi và tự phục hồi (Fault Tolerance & Resilience)

• Thiết kế hệ thống với giả định: Mọi thứ đều có thể chết (database sập, API bên thứ ba timeout, mạng nghẽn).
• Kỹ sư thiết kế cơ chế Circuit Breaker, Retry, Dead Letter Queue và Data Fallback — những thứ AI không thể tự sinh ra nếu bạn không yêu cầu rõ ràng.

3. Case Study: Xây dựng hệ thống Đặt vé xem phim (Flash Sale)

Hãy nhìn sự khác biệt trong cách tiếp cận cùng một đề bài:

• Tư duy Coder:
  • Hỏi AI: "Viết cho tôi API đặt vé xem phim bằng Spring Boot/Node.js."
  • AI tạo ra đoạn code: Nhận request ──> Check database xem ghế trống không ──> Insert vào bảng Orders ──> Return 200 OK.
  • Hậu quả: Khi có 50.000 người cùng bấm đặt vé một hàng ghế hot trong 1 giây, hệ thống bị nghẽn DB (Database Lock), ghi đè dữ liệu (Race Condition), dẫn đến bán 1 ghế cho nhiều người.
• Tư duy Software Architect:
  • Nhận diện bài toán tải cao (High Concurrency) và tranh chấp tài nguyên (Resource Contention).
  • Thiết kế giải pháp phân lớp:
    1. Đưa request vào hàng đợi phân tán (Redis Queue) để xả tải cho Database.
    2. Dùng Redis Distributed Lock hoặc Optimistic Locking để đảm bảo chỉ duy nhất một user giữ ghế trong 5 phút.
    3. Trả về trạng thái "Đang xử lý" ngay lập tức cho client (Async Processing).
    4. Cập nhật Database thật sau khi đã xác thực giao dịch thành công.
  • Hành động với AI: Sau khi đã có thiết kế này, kỹ sư mới giao việc cho AI: "Viết module Redis Distributed Lock với cơ chế tự động release sau 300 giây và xử lý retry 3 lần."

4. Bảng checklist chuyển đổi vai trò hàng ngày