Rubber duck debugging: Vì sao con vịt lại fix được bug

Nếu bạn bước vào góc làm việc của một dev và thấy có một con vịt cao su vàng choé nằm cạnh bàn phím, đừng vội nghĩ họ thích chơi đồ chơi nhà tắm. Rất có thể, đó là "senior developer" thâm niên nhất phòng, người đã giúp họ gỡ không biết bao nhiêu quả bom bug mà không cần tốn một dòng code đáp trả.

Kỹ thuật này có tên là Rubber Duck Debugging (Gỡ lỗi cùng vịt cao su), và dù nghe có vẻ tấu hài, nó lại là thứ vũ khí bí mật được dân lập trình chuyền tay nhau dùng mỗi ngày.

Rubber duck debugging là gì?

Luật chơi vô cùng đơn giản: Khi bạn kẹt cứng với một con bug không lối thoát, hãy lôi con vịt cao su ra và bắt đầu giải thích đoạn code của mình cho nó nghe, từng dòng một.

Con vịt sẽ làm gì? Nó sẽ ngồi im, không ngắt lời, không gợi ý, và tuyệt đối không phán xét. Thế nhưng, điều kỳ diệu thường xảy ra ngay giữa câu chuyện: bạn bỗng khựng lại, đập đùi cái đét và thốt lên "À, tao thấy lỗi ở đâu rồi!"

Cái tên này xuất phát từ cuốn sách kinh điển The Pragmatic Programmer, kể về một lập trình viên luôn kè kè con vịt bên cạnh để "tâm sự" mỗi khi gặp ca khó. Tất nhiên, vịt chỉ là biểu tượng. Trên bàn làm việc của tôi đôi khi chẳng có vịt, mà là một ly cà phê cạn đáy, một chậu xương rồng mini, hay đôi lúc là con mèo nhà hàng xóm đi lạc qua cửa sổ. Miễn là nó im lặng lắng nghe.

Vì sao "nói chuyện với vịt" lại siêu hiệu quả?

Khi tự đọc lại code trong đầu, bộ não chúng ta cực kỳ lười biếng và thích đi đường tắt. Nó chỉ nhìn thấy thứ mà nó muốn thấy (code đang làm gì theo ý bạn), chứ không chịu nhìn thứ mà code thực sự đang làm. Bạn có thể quét qua dòng i <= arr.length hàng chục lần mà não vẫn tự động bỏ qua lỗi, vì tiềm thức đã đinh ninh vòng lặp chuẩn xác rồi.

Việc ép bản thân phải thốt thành lời sẽ bẻ gãy cái vòng lặp lười biếng đó bằng ba cách:

1. Buộc bạn phải phanh gấp: Tốc độ nói bao giờ cũng chậm hơn tốc độ luồng suy nghĩ chạy trong đầu. Sự chậm lại đó cho não bộ khoảng không gian cần thiết để soi xét từng chi tiết nhỏ.

2. Ép tư duy phải tuần tự: Bạn không thể nhảy cóc khi giải thích cho người khác (hoặc cho vịt). Bạn bắt buộc phải nói: "Đầu tiên hàm này nhận vào mảng này, xong nó đi qua vòng lặp...". Chính lúc ép mọi thứ vào khuôn khổ tuần tự đó, những lỗ hổng logic bắt đầu hở ra.

3. Lôi tẩy những giả định ngầm: Bug hiếm khi nằm ở chỗ bạn nghi ngờ, mà thường ẩn nấp ở những thứ bạn đinh ninh là "hiển nhiên đúng". Khi phải cất tiếng thưa với vịt rằng "chỗ này biến x chắc chắn có giá trị", tự khắc một câu hỏi khác nhảy vào đầu: "Chắc chắn thật không mày?"

Nhìn vào một ca thực chiến cụ thể

Lấy đoạn code tính tổng giỏ hàng này làm ví dụ. Trông nó mượt mà, chạy không hề báo một dòng lỗi đỏ nào, nhưng kết quả trả về thì lúc nào cũng sai bét nhè:

JavaScript

function tinhTong(gioHang) {
  let tong = 0;
  for (let i = 0; i <= gioHang.length; i++) {
    tong += gioHang[i]?.gia * gioHang[i]?.soLuong || 0;
  }
  return tong;
}

Giờ thử lẩm bẩm với vịt xem sao: "Vịt ơi, hàm này khởi tạo tổng bằng không. Sau đó nó cho i chạy từ 0 cho đến khi... nhỏ hơn hoặc bằng độ dài của giỏ hàng...".

Đến đây thôi là nhiều ông sẽ tự vả vào trán mình rồi. Mảng có 3 phần tử thì index cao nhất chỉ là 2, việc dùng dấu <= khiến vòng lặp cố đấm ăn xôi chạy thêm một nhịp thừa thãi ở cuối.

Cái hay ở đây là gì? Toán tử ?. và || 0 đã đóng vai trò như một lớp ngụy trang hoàn hảo, giấu nhẹm cái lỗi undefined đi nên máy không hề kêu ca, chỉ là con số cuối cùng lệch đi đâu mất. Miếng vá || 0 vô tình che lấp luôn việc bạn đang xử lý sai logic từ gốc. Giải thích thành lời chính là chiếc máy scan lôi sạch những kiểu "chữa cháy" tạm bợ này ra ánh sáng.

Bí kíp trò chuyện với vịt sao cho đúng bài

Đừng chỉ lẩm bẩm như đọc thần chú, hãy biến nó thành một cuộc "kiểm toán" thực sự:

• Chốt mục tiêu trước: "Đoạn code này sinh ra để làm cái khỉ gì?" (Nhiều khi lỗi nằm ngay ở việc từ đầu bạn đã hiểu sai đề bài).

• Mô tả thực tế: "Thế nhưng hiện tại nó đang giở trò gì?" Càng chi tiết càng tốt.

• Băm nhỏ từng dòng: Đừng tóm tắt chung chung. Đi qua từng dòng và chỉ rõ giá trị đầu vào là gì.

• Bám sát giá trị biến: Thay vì nói "đoạn này cộng dồn", hãy đọc to: "Đến vòng lặp thứ 2, biến tong đang là 150 nghìn".

• Đánh dấu chỗ ngập ngừng: Chỗ nào miệng bạn bỗng khựng lại, lúng búng kiểu "chắc là..." hay "đáng lẽ ra là..." — đích thị chỗ đấy đang có ma.

Không có vịt thì xài tạm gì?

Làm việc ở văn phòng mở, ngồi ôm con vịt cao su bóp kêu chít chít rồi lẩm bẩm một mình có thể khiến đồng nghiệp nhìn bạn bằng ánh mắt hơi e dè. Đừng lo, cơ chế cốt lõi nằm ở hành vi diễn đạt, chứ không nằm ở ngoại hình con vật. Bạn có thể thay thế bằng:

• Mở Notepad/Notion: Gõ lại lỗi hệt như lúc bạn định lên stackoverflow hỏi bài. Nhiều dev thú nhận họ chưa kịp bấm nút đăng câu hỏi thì tự đọc lại đã thấy đáp án nằm lù lù ở đó từ bao giờ.

• Soạn tin nhắn (nhưng đừng bấm gửi vội): Viết một chiếc message dài cho đồng nghiệp, tóm tắt ngữ cảnh, input, output mong đợi và thực tế. Nửa số lần viết xong là bạn tự xóa vì bỗng dưng... thông minh ra.

• Viết comment giải thích code: Ép mình viết lại ý nghĩa của đoạn code ngay trên IDE trước khi sửa.

Khi nào nên đuổi "vịt" về chuồng?

Rubber duck debugging cực kỳ ăn tiền khi bạn vấp phải lỗi logic, lỗi tư duy của chính mình. Nhưng nó hoàn toàn vô tác dụng nếu bạn đang kẹt vì thiếu kiến thức nền tảng — con vịt không thể thì thầm cho bạn biết một thư viện lạ hoắc hoạt động ra sao nếu bạn chưa từng mở tài liệu (documentation) của nó ra đọc.

Nếu đã giảng giải nát nước mà con vịt vẫn trơ mắt nhìn bạn bế tắc, đó là lúc nên quẳng nó lên bàn và đi tìm một con người thật sự. Và tin tôi đi, lúc đó bạn đã có sẵn trong đầu một mớ thông tin mạch lạc, việc nhờ đồng nghiệp gỡ rối sẽ nhanh hơn gấp nhiều lần.

Nhớ lại bản thân tôi có lần cặm cụi debug hệ thống suốt 3 tiếng không xong, đành quay sang gọi một bạn đồng nghiệp ngồi cạnh: "Ê, nghe tao kể cái này tí...". Chưa dứt câu thứ hai tự khắc nhận ra mình truyền nhầm tham số ở hàm gọi API bên dưới. Chỉ muốn chui xuống đất vì quê, nhưng công nhận là linh nghiệm cực kỳ!

Kỹ thuật đỉnh cao đôi khi lại ẩn giấu đằng sau những thứ ngớ ngẩn nhất. Lần tới, nếu bạn thấy mình đang trân trân nhìn màn hình quá 15 phút mà không nhúc nhích được dòng code nào, hãy tìm một "đồng nghiệp im lặng" nào đó ở góc bàn và bắt đầu kể chuyện đi nhé!