Đừng bắt đầu với framework: một cách chọn công cụ có chủ đích

Khi nhận một yêu cầu mới, phản xạ của nhiều developer là mở trình duyệt và tìm “framework tốt nhất cho X”. Câu hỏi đó gần như luôn sai thứ tự: ta đang chọn lời giải trước khi hiểu bài toán.

Bài này đề xuất một quy trình bốn bước, đủ ngắn để dùng trong một buổi chiều nhưng đủ chặt để bạn bảo vệ được lựa chọn của mình trước team.

Bước 1: Viết ra bài toán bằng ngôn ngữ của người dùng

Trước khi nghĩ đến công nghệ, hãy viết một đoạn ngắn: ai dùng, họ làm gì, và điều gì xảy ra nếu hệ thống chậm hoặc lỗi. Nếu không viết được đoạn này, bạn chưa sẵn sàng chọn công cụ.

Bước 2: Liệt kê ràng buộc thật

• Ai sẽ bảo trì sau sáu tháng — bạn, team, hay một người chưa được tuyển?
• Ngân sách hạ tầng mỗi tháng là bao nhiêu?
• Có yêu cầu SEO, offline, hay thời gian thực không?
• Hạn chót có cố định không?

Ràng buộc là thứ loại bỏ lựa chọn nhanh nhất. Một team hai người với hạn chót bốn tuần không nên tự vận hành Kubernetes, dù công cụ đó tốt đến đâu.

Bước 3: So sánh tối đa ba lựa chọn

Đặt các lựa chọn vào một bảng đơn giản và chấm điểm theo đúng những ràng buộc ở bước 2. Đừng chấm theo số sao trên GitHub.

# Quyết định: chọn framework cho blog

## Bối cảnh
Một tác giả, cần SEO tốt, ngân sách gần như 0.

## Lựa chọn
1. Next.js + Vercel
2. Astro + Netlify
3. WordPress tự host

## Kết luận
Chọn (1) vì team đã quen React và cần khu vực admin.

## Hệ quả
Phụ thuộc Vercel; chấp nhận được ở giai đoạn đầu.

Bước 4: Ghi lại và đặt ngày xem lại

Một quyết định không được ghi lại sẽ bị tranh luận lại mỗi quý. Lưu file quyết định ngay trong repository và hẹn ngày xem lại, ví dụ sau ba tháng chạy production.

Công cụ tốt nhất là công cụ mà team của bạn có thể vận hành lúc 2 giờ sáng.