Ghi chép thực tế ③: Khảo sát kiến trúc bằng prototype 2 ngày + đo lường thực tế

Tình huống triển khai AI

Khi chuyển một hệ thống cũ sang nền tảng mới, việc đến đầu tiên là khảo sát kiến trúc. Theo cách truyền thống, phải bố trí nhân lực trong khoảng 1 tháng. Thành quả là bảng so sánh trên giấy và con số ước tính. Vấn đề là tính đúng đắn của bảng so sánh đókhông ai kiểm chứng được cho đến khi việc phát triển thực tế bắt đầu. "Kiến trúc đã chọn thực ra không đáp ứng được yêu cầu hiệu năng" — điều này thường chỉ vỡ lẽ vào lúc đã không thể quay đầu. Với dự án lần này, chúng tôi đã từ bỏ cách làm đó.

Làm một "prototype chạy được" trong 2 ngày, rồi quyết định bằng đo lường thực tế.

• 1. Phân tích hệ thống hiện hành — Dùng AI agent (Claude Code) rà soát toàn bộ màn hình, tính năng và quyền hạn hiện hành, sắp xếp thành ma trận theo vai trò gồm 14 màn hình, 45 tính năng, 527 mục và sổ theo dõi 46 vấn đề kèm phân loại xử lý
• 2. Xây dựng prototype (2 ngày làm việc thực tế) — Giữ nguyên kiến trúc đang cân nhắc, xây dựng prototype chạy được gồm API + màn hình demo. Quy mô khoảng 66.000 dòng (API khoảng 27.000 dòng + màn hình khoảng 39.000 dòng)
• 3. Nạp dữ liệu và đo lường thực tế — Nạp 10.000 bản ghi dữ liệu, đo phản hồi của toàn bộ API và toàn bộ màn hình. "Kiến trúc này, với quy mô này, đạt tốc độ này" trở thành con số cụ thể

Nhờ đo lường thực tế, cả sự suy giảm lẫn biện pháp khắc phục đều được nói bằng "sự thật".

Ở lần đo đầu tiên khi nạp 10.000 bản ghi, một số API mất 22 giây, còn hiển thị màn hình vượt quá 90 giây. Nếu chỉ khảo sát trên giấy thì đến đây phải quay về vạch xuất phát, nhưng vì có vật thật nêncó thể xác định chỗ nào chậm và đưa ra biện pháp. Từ rà soát lại thiết kế index đến thay đổi mẫu truy cập, chúng tôi áp dụng các biện pháp theo 4 giai đoạn và đo lại, kết quả là —toàn bộ API từ 22 giây xuống dưới 3 giây, toàn bộ màn hình từ hơn 90 giây xuống mức 2 giây. Với truy xuất đơn lẻ, chúng tôi xác nhận qua đo lường thực tế mức cải thiện gấp 600 lần. Vì đã chốt kiến trúc cùng với những con số này, nỗi lo "có thể không đạt hiệu năng khi vận hành thật" cũng được giải tỏa hoàn toàn.

Lẽ thường về "khảo sát" đang thay đổi.

Bản chất của cách làm này không phải là bản thân tốc độ.cơ sở để ra quyết định chuyển từ "phỏng đoán" sang "đo lường thực tế". Bảng so sánh trên giấy trở thành prototype chạy được cùng dữ liệu đo, "chắc là chịu được" trở thành "với quy mô này thì thời gian phản hồi là bấy nhiêu", và thời điểm vỡ lẽ chuyển từ giữa lúc phát triển thật sang giữa lúc khảo sát kiến trúc (= giai đoạn có thể làm lại bao nhiêu cũng được). Nay prototype có thể được làm với chi phí bỏ đi cũng không tiếc. Vì thế, làm ra rồi mới quyết định. Cách tiến hành khảo sát kiến trúc, lựa chọn công nghệ và PoC đang được viết lại từ gốc rễ nhờ sự xuất hiện của AI agent.

Bạn có đang gặp khó khăn trong tình huống tương tự?

"Không thể chốt được kiến trúc cho hệ thống mới", "không thể phán định đề xuất của nhà cung cấp có hợp lý hay không", "không muốn tốn cả mấy tháng cho PoC" — với việc khảo sát đó,vật chạy được + giá trị đo lường thực tếhãy tiến hành cùng chứ?

Loạt bài "Legacy to AI — Ghi chép thực tế"

• Tổng hợp: 22 hệ thống và 246 nghìn dòng code trên một chiếc PC — ghi chép đo lường thực tế về 3,5 tháng phát triển với AI
• Ghi chép thực tế ①: Đổi mới toàn diện một hệ thống Java 20 năm tuổi trong khoảng 1 tuần
• Ghi chép thực tế ②: Tạo lối vào mới cho hệ thống lõi mà không thay đổi 0 dòng mã hiện có
• Ghi chép thực tế ③: Hoàn tất việc khảo sát kiến trúc vốn mất cả tháng bằng prototype 2 ngày + đo lường thực tế (bài viết này)

* Các con số trong bài viết này là giá trị đo lường thực tế tại thời điểm cuối tháng 7 năm 2026. Thành quả phát triển sẽ khác nhau tùy theo tình trạng và yêu cầu của hệ thống.