Login

Rubber duck debugging: giải thích cho chú vịt để tìm ra lỗi

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Có bao giờ bạn loay hoay với một lỗi cả giờ liền, đến khi nhờ đồng nghiệp xem giúp, vừa mới mở miệng giải thích thì tự nhiên bạn nhận ra lỗi ở đâu? Hiện tượng này phổ biến đến mức có hẳn một kỹ thuật tên là rubber duck debugging (debug bằng vịt cao su). Nghe vui nhưng nó thực sự hiệu quả.

Rubber duck debugging là gì?

Ý tưởng đơn giản: bạn đặt một con vịt cao su (hoặc bất kỳ vật gì, thậm chí một cái cốc) lên bàn rồi giải thích code của mình cho nó nghe, từng dòng một, như thể nó là người mới chưa biết gì. Trong lúc nói ra thành lời, bạn buộc phải diễn đạt rõ ràng điều mình nghĩ là code đang làm, và thường phát hiện ra chỗ thực tế khác với giả định.

Tên gọi bắt nguồn từ một câu chuyện được kể trong sách lập trình nổi tiếng, trong đó một lập trình viên mang theo vịt cao su để nói chuyện khi gỡ lỗi. Bạn không cần phải nhớ nguồn gốc, chỉ cần biết kỹ thuật này đã được rất nhiều người dùng.

Vì sao nó hiệu quả?

  • Chậm lại: nói chậm hơn nhiều so với suy nghĩ, nên bạn không thể nhảy cóc qua những bước "hiển nhiên".
  • Buộc diễn đạt cụ thể: khi nói "chỗ này lấy dữ liệu", bạn phải nói chính xác dữ liệu nào, từ đâu, kiểu gì.
  • Lộ ra giả định: bạn tưởng biến này luôn có giá trị, nhưng khi phải giải thích tại sao, bạn nhận ra không có gì đảm bảo.
  • Đổi góc nhìn: từ người viết code chuyển sang người giải thích, bạn nhìn code như người ngoài.
  • Giảm căng thẳng: nói chuyện với một "người nghe" kiên nhẫn làm đầu óc nhẹ nhõm hơn.

Cách thực hiện từng bước

  1. Chuẩn bị "người nghe": con vịt, hình nhân, hoặc cửa sổ ghi chú trống. Nếu ở nơi công cộng, bạn có thể nói thầm hoặc gõ ra giấy.
  2. Nêu mục tiêu: "Đoạn code này lẽ ra phải làm X."
  3. Nêu hiện tượng thực tế: "Nhưng thực tế nó cho ra Y."
  4. Đi qua code từng dòng, giải thích mỗi dòng làm gì và vì sao. Đừng nói "chỗ này chắc là đúng", hãy chứng minh nó.
  5. Dừng lại ở điểm vấp: bất cứ lúc nào bạn ngập ngừng, nói "ừm" hoặc không chắc, đó thường là nơi chứa lỗi.
  6. Kiểm chứng: kiểm tra điểm nghi ngờ đó bằng log hoặc debugger.

Ví dụ minh họa

Giả sử bạn viết hàm đếm số lần xuất hiện của từng từ nhưng kết quả sai:

function countWords(text) {const counts = {};const words = text.split(' ');for (const word of words) {counts[word] = counts[word] + 1;}return counts;}

Khi giải thích cho vịt: "Mình tách chuỗi thành các từ. Với mỗi từ, mình lấy số lần đếm hiện tại cộng 1. À, nhưng lần đầu thấy từ đó, counts[word] là gì nhỉ? Là undefined, và undefined + 1 ra NaN!" Lỗi được tìm ra chỉ nhờ giải thích. Cách sửa:

counts[word] = (counts[word] || 0) + 1;

Phiên bản nâng cao: viết ra thay vì nói

Không phải ai cũng muốn nói chuyện với đồ vật. Bạn có thể:

  • Viết câu hỏi như đang đăng lên diễn đàn. Việc soạn một câu hỏi rõ ràng (mục tiêu, đã thử gì, kết quả ra sao) nhiều khi tự nó dẫn đến câu trả lời trước khi bấm gửi.
  • Vẽ sơ đồ luồng dữ liệu trên giấy hoặc bảng trắng.
  • Giải thích cho đồng nghiệp nhưng đừng chờ họ trả lời, đôi khi họ chỉ cần ngồi đó nghe.
  • Ghi lại bằng comment: viết ngắn gọn điều mỗi đoạn đang làm, nếu có đoạn không viết được, đó là điểm đáng nghi.

Khi nào nên dùng?

Rubber duck đặc biệt hợp khi:

  • Lỗi logic: code chạy nhưng kết quả sai và không có thông báo lỗi.
  • Bạn đã nhìn đoạn code quá lâu và mắt "mù" với nó.
  • Bạn đang chuẩn bị hỏi người khác, hãy thử giải thích trước cho vịt.
  • Bạn muốn hiểu code người khác viết: giải thích từng đoạn giúp kiểm tra mức độ hiểu của mình.

Nếu giải thích xong mà vẫn không tìm ra, bạn đã có sẵn một bản mô tả vấn đề rõ ràng để gửi cho đồng nghiệp hoặc đăng lên cộng đồng, và người khác sẽ giúp bạn dễ dàng hơn nhiều.

Kết luận

Kỹ thuật này gần như miễn phí, không cần công cụ, chỉ cần sẵn lòng nói chậm lại và nói rõ. Hãy kiếm một chú vịt (hoặc một món đồ chơi nhỏ) đặt cạnh màn hình, lần tới khi bí lỗi hãy thử trước khi hỏi ai khác.

Nếu bạn muốn học cách tư duy giải quyết vấn đề có hệ thống hơn, hãy xem các lộ trình trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment