Think Like a Developer #7: Debug Thinking - "Lỗi không phải là thất bại, lỗi là manh mối"
Màn hình đỏ lòm. Một đống chữ tiếng Anh bay ra. Bạn hoảng, copy nguyên đoạn paste vào AI rồi cầu nguyện.
Developer nhìn cũng cái màn hình đó. Họ không hoảng. Họ thấy... cơ hội.
Khác biệt không phải ở kinh nghiệm. Khác biệt ở tư duy.
Lỗi không phải là thất bại. Lỗi là manh mối. Và bài này sẽ dạy bạn cách đọc manh mối như thám tử.
Tại sao người no-code sợ lỗi
Vì bạn coi lỗi là dấu hiệu "mình sai rồi, mình dở rồi, mình không hợp với cái này".
Cảm xúc đó là tự nhiên. Nhưng nó sai.
Trong thế giới developer, lỗi là chuyện hàng ngày. Một dev senior 10 năm kinh nghiệm vẫn gặp lỗi mỗi ngày. Khác biệt là: họ không coi lỗi là vấn đề. Họ coi lỗi là dữ liệu.
Khi app chạy đúng, bạn không học được gì. Khi app báo lỗi, máy tính đang cố nói cho bạn biết chính xác cái gì sai và sai ở đâu. Đó là món quà.
Vấn đề là bạn không đọc được món quà đó. Bạn thấy "Uncaught TypeError: Cannot read property 'map' of undefined at Dashboard.jsx:42" và bạn thấy chữ ngoằn ngoèo.
Developer nhìn dòng đó thấy gì? Họ thấy:
Có một biến nào đó đang là undefined (chưa có giá trị) Bạn đang cố gọi hàm map trên nó Lỗi xảy ra ở file Dashboard.jsx, dòng 42
Ba thông tin cụ thể. Không mơ hồ. Đủ để biết bắt đầu sửa từ đâu.
Developer không thông minh hơn bạn. Họ chỉ biết cách đọc.
Lỗi nói cái gì với bạn
Hầu hết error message đều có 3 phần:
Phần 1: Loại lỗi. TypeError, ReferenceError, SyntaxError, NetworkError... Mỗi loại lỗi tương ứng với một kiểu sai khác nhau.
TypeError nghĩa là bạn đang dùng cái gì đó sai kiểu. Ví dụ: cố gọi hàm trên một số, hoặc cố cộng chuỗi với undefined.
ReferenceError nghĩa là bạn đang gọi tên một thứ không tồn tại. Như gọi tên người mà người đó không có trong nhà.
SyntaxError nghĩa là bạn viết sai cú pháp. Thiếu dấu ngoặc, thiếu dấu phẩy, sai chính tả.
NetworkError nghĩa là không kết nối được tới đâu đó. API chết, mạng yếu, URL sai.
Bạn không cần học hết. Chỉ cần biết: mỗi loại lỗi gợi ý cho bạn nguyên nhân khác nhau.
Phần 2: Mô tả cụ thể. "Cannot read property 'map' of undefined" nói rõ: có cái gì đó bạn tưởng là một danh sách, nhưng nó đang là undefined.
Phần 3: Vị trí. File nào, dòng nào. Đây là bản đồ chỉ thẳng tới hiện trường.
Khi gặp lỗi, đừng hoảng. Đọc 3 phần này trước.
4 câu hỏi cần hỏi khi gặp lỗi
Developer có một quy trình chuẩn. Mình gọi nó là 4W của debug:
Câu 1: What? Lỗi nói cái gì?
Đọc kỹ error message. Đừng skim. Đừng đoán. Đọc từng chữ. Có dấu ngoặc nào không? Có tên biến nào không? Tên file gì, dòng bao nhiêu?
90% bug được sửa chỉ bằng việc đọc kỹ error message. Nghiêm túc.
Câu 2: When? Lỗi xảy ra khi nào?
Khi load trang? Khi bấm nút? Khi gửi form? Khi load data? Lỗi xuất hiện ngay từ đầu hay sau một hành động cụ thể?
Câu trả lời này khoanh vùng cực mạnh. Lỗi xuất hiện khi bấm nút "Lưu" thì bạn chỉ cần nhìn code của nút đó. Không cần đọc cả app.
Câu 3: What changed? Thay đổi gì gần nhất?
Code này tuần trước chạy ngon. Hôm nay hỏng. Bạn thay đổi cái gì?
Phần lớn bug đến từ thay đổi cuối cùng. Đó là lý do developer hay nói "nó vẫn chạy mà, tôi có làm gì đâu". Câu nói đó thường sai. Họ vừa làm gì đó. Họ chỉ không nhớ.
Bạn đã prompt AI sửa gì? Đã sửa tay phần nào? Đã thêm tính năng gì? Quay lại kiểm tra.
Câu 4: Can I reproduce? Có thể tái tạo lỗi không?
Bạn có thể làm cho lỗi xảy ra lại không? Bằng cách nào?
Lỗi mà tái tạo được là lỗi sửa được. Lỗi xuất hiện random thì khó hơn nhiều, nhưng vẫn có cách. Bước đầu tiên luôn là tìm cách tái tạo.
4 câu hỏi này áp dụng cho mọi loại lỗi, mọi tool, mọi framework. Là tư duy, không phải kỹ thuật.
Sai lầm điển hình của người no-code khi gặp lỗi
Sai lầm 1: Copy nguyên đoạn lỗi paste cho AI rồi nói "sửa giúp tôi"
AI sẽ đoán. Nó đoán có thể trúng, có thể trật. Nhưng quan trọng hơn: bạn không học được gì. Lần sau gặp lỗi tương tự bạn vẫn không biết tự sửa.
Sai lầm 2: Bảo AI "kiểm tra toàn bộ code"
AI sẽ đọc loạn xạ và "phát hiện" ra hàng loạt vấn đề không liên quan. Nó sẽ sửa luôn cả những thứ đang chạy đúng. Kết quả: app hỏng thêm chỗ mới.
Sai lầm 3: Hoảng và bắt đầu sửa tùm lum
Mỗi lần sửa thử là một biến số mới. Sửa 3 chỗ cùng lúc, không biết chỗ nào fix được, chỗ nào tạo bug mới. Vòng lặp địa ngục.
Sai lầm 4: Đổ tại AI
"Tool này dở quá, AI ngu quá." Có thể đôi khi đúng. Nhưng phần lớn thời gian, AI làm đúng theo prompt mơ hồ của bạn. Lỗi là cơ hội để hỏi: prompt mình đã rõ chưa?
Cách nói chuyện với AI khi gặp lỗi
Đây là template prompt mình dùng mỗi lần gặp lỗi:
Tôi gặp lỗi này:
[paste full error message ở đây]
Context:
Lỗi xảy ra khi: [bạn đang làm gì thì lỗi xuất hiện]
Trước đó tôi đã thay đổi: [thay đổi gần nhất là gì]
File liên quan: [tên file nếu error chỉ ra]
Trước khi sửa, hãy giải thích cho tôi:
Loại lỗi này nghĩa là gì
Tại sao nó xảy ra
Có những cách nào để sửa, ưu nhược điểm mỗi cách
Sau đó đề xuất cách sửa đơn giản nhất, chỉ sửa đúng phần liên quan.
Tại sao prompt này hiệu quả?
Bạn cung cấp đủ context cho AI hiểu tình huống. AI giải thích trước khi sửa, để bạn học được gì đó. AI đề xuất phương án thay vì làm ngay, để bạn có lựa chọn. AI bị giới hạn chỉ sửa phần liên quan, không động loạn xạ.
Khác biệt giữa "sửa giúp tôi" và prompt trên: một bên là cầu nguyện, một bên là thám tử.
Đọc 3 error message mẫu
Thử cùng mình phân tích 3 lỗi phổ biến:
Lỗi 1:
TypeError: Cannot read property 'name' of undefined at UserProfile.jsx:15
Phân tích:
What: TypeError, cố đọc property name của thứ đang là undefined
Where: File UserProfile.jsx, dòng 15
Why có thể: Component đang render trước khi data về. User chưa load xong mà đã cố truy cập user.name
Cách sửa thường gặp: Thêm điều kiện kiểm tra, nếu user chưa có thì hiển thị loading
Lỗi 2:
Failed to fetch NetworkError when attempting to fetch resource
Phân tích:
What: NetworkError, không gọi được tới server
Why có thể: API endpoint sai, server đang chết, hoặc thiếu CORS config
What changed: Bạn vừa đổi URL API? Vừa deploy server mới?
Cách sửa thường gặp: Kiểm tra URL, kiểm tra server đang chạy không, mở Network tab xem request thực tế
Lỗi 3:
SyntaxError: Unexpected token '}' at line 47
Phân tích:
What: SyntaxError, có dấu } không đúng chỗ
Where: Dòng 47, nhưng SyntaxError thường do dòng trước đó
Why có thể: Thiếu dấu ngoặc mở, hoặc dư một dấu ngoặc đóng
Cách sửa thường gặp: Đếm dấu ngoặc, hoặc dùng AI để format lại code
Thấy không? Cùng một quy trình. Cùng câu hỏi. Khác lỗi khác kết luận.
Bài tập thực hành 15 phút
Lần tới bạn gặp lỗi trong khi vibe code, đừng cuống. Làm theo các bước này:
Bước 1 (2 phút): Đọc kỹ error message. Viết ra giấy 3 thông tin: loại lỗi gì, mô tả gì, ở file/dòng nào.
Bước 2 (3 phút): Trả lời 4 câu hỏi:
Lỗi xảy ra khi tôi làm gì?
Thay đổi gần nhất của tôi là gì?
Tôi có thể làm lỗi xuất hiện lại không?
Phần nào của app bị ảnh hưởng?
Bước 3 (5 phút): Viết prompt theo template ở trên. Gửi cho AI. Đọc câu trả lời. Hiểu trước khi sửa.
Bước 4 (5 phút): Áp dụng cách sửa. Test lại. Lỗi hết chưa? Có lỗi mới không?
Nếu chưa có lỗi nào để debug, mở app của bạn lên, cố tình làm sai thứ gì đó (xóa một dòng, đổi tên biến). Tạo lỗi. Tập đọc lỗi. Tập sửa.
Đây là kỹ năng quan trọng nhất phase 3. Phase 1 dạy bạn cách nhìn, phase 2 dạy bạn cách thiết kế, phase 3 dạy bạn cách xử lý khi mọi thứ đi sai. Mà sẽ luôn có lúc sai.
Tư duy quan trọng
Lỗi không phải là dấu hiệu bạn dở. Lỗi là dấu hiệu bạn đang build cái gì đó thật. Code không có lỗi là code không tồn tại.
Mỗi lần debug thành công, bạn học được một thứ mới về cách hệ thống hoạt động. Sau 6 tháng vibe code có debug đàng hoàng, bạn sẽ hiểu app của mình ở mức mà người chỉ prompt mãi không bao giờ đạt được.
Lần tới màn hình đỏ lòm, hít một hơi. Mở mắt ra. Đọc.
Lỗi đang nói chuyện với bạn. Học cách nghe đi.
Tuần sau: Bài 8 — Boundary Thinking: "Nghĩ về cái sẽ sai, không chỉ cái sẽ đúng". App của bạn chạy ngon, cho đến khi ai đó nhập tên dài 500 ký tự, hoặc bấm nút submit 5 lần liên tiếp, hoặc mất mạng giữa chừng. Bạn sẽ học cách lường trước những thứ "không ai làm thế đâu" mà người ta vẫn làm.