Kẹt là bình thường — quy tắc hai mươi phút

TL;DR: Kẹt là trạng thái mặc định của mọi người viết code, kể cả người làm nghề mười năm — khác biệt nằm ở quy trình thoát kẹt. Quy tắc thực dụng: kẹt quá hai mươi phút mà vùng nghi ngờ không thu hẹp thì dừng thử tiếp, vì cách đang dùng sai. Khi cần nhờ trợ giúp, một câu hỏi trả lời được có đủ bốn thành phần: đoạn code tối thiểu tái hiện lỗi, output thật nguyên văn, kết quả mong đợi, và giả thuyết đã thử. Thiếu một trong bốn, người đọc không đủ dữ kiện để trả lời — và thường chính bạn tự thấy đáp án ngay lúc viết đủ bốn phần đó.

23 giờ 40 phút, bạn đang làm bài tập tính điểm trung bình của lớp. Dòng thứ hai đỏ ngoằn, chương trình dừng giữa chừng. Bạn đọc lại ba lần, đổi một dấu ngoặc, chạy lại — vẫn y nguyên lỗi đó.

Bạn mở group Facebook 200 người của lớp lập trình, gõ: "Code em bị lỗi, mọi người xem giúp em với ạ." Rồi chờ. Mười lăm phút sau, một bình luận duy nhất: "Lỗi gì vậy bạn, dán code lên xem." Bạn dán đúng đoạn đã sai — không có output, không nói kết quả bạn đang chờ là gì. Bình luận tiếp theo, nếu có, sẽ hỏi lại đúng câu bình luận đầu vừa hỏi.

Kẹt không phải điều lạ trong tình huống này. Thứ thật sự thiếu là một câu hỏi đủ để người khác trả lời được, và bài này lo đúng chỗ đó.

Bài này lo đúng một việc: viết một câu hỏi nhờ trợ giúp đủ để người khác — hoặc chính bạn — trả lời được.

1. Analogy — gọi bác sĩ lúc nửa đêm vì con sốt

Một người mẹ gọi điện cho bác sĩ lúc nửa đêm vì con sốt. Câu "Con em sốt, phải làm sao bác sĩ ơi" không giúp bác sĩ chẩn đoán được gì — sốt bao nhiêu độ, từ khi nào, đã uống thuốc gì chưa đều còn bỏ trống. Bác sĩ có nghề sẽ hỏi ngược lại đúng bốn câu đó trước khi dám khuyên tiếp. Người mẹ chuẩn bị sẵn bốn câu trả lời trước khi gọi thì cuộc gọi rút ngắn còn đúng một lượt.

2. Dừng thử tiếp lúc nào?

Bài trước dạy bạn vòng giả thuyết: đoán nguyên nhân, kiểm chứng, thu hẹp dần. Nhưng vòng đó không chạy mãi mãi — nó cần một mốc dừng. Mốc đó không đo bằng đồng hồ; nó là một câu hỏi: sau hai mươi phút, vùng nghi ngờ của bạn có nhỏ lại không? Nếu bạn vẫn nghi ngờ đúng những dòng đã nghi ngờ lúc bắt đầu, cách bạn đang thử sai. Cố thêm mười phút nữa bằng đúng cách đó không có lý do gì sẽ ra khác.

Ba việc đáng làm hơn là cố thêm: đọc to lại đoạn code cho chính mình nghe, vì tai bắt lỗi mà mắt đã quen bỏ qua; rời máy vài phút rồi quay lại với mắt mới; hoặc chuyển sang viết câu hỏi nhờ trợ giúp ở mục dưới. Chính việc ép mình viết đủ bốn thành phần của một câu hỏi tốt thường làm lộ ra đáp án trước khi bạn kịp gửi nó đi.

3. Bốn thành phần của một câu hỏi trả lời được

Quay lại đúng câu hỏi ở đầu bài:

Code em bị lỗi, mọi người xem giúp em với ạ.

Người đọc không trả lời được câu này, vì bốn thứ đều thiếu: không thấy đoạn code nào, không biết máy báo lỗi gì, không biết bạn đang mong chương trình làm ra cái gì, không biết bạn đã thử sửa cách nào chưa. Bốn khoảng trống đó chính là bốn thành phần bạn phải tự lấp trước khi gõ nút gửi.

Viết lại đúng tình huống đầu bài, dán nhãn từng phần:

Đoạn code tối thiểu tái hiện lỗi:

diem = "8"
trung_binh = diem / 2
print(trung_binh)

Chỉ ba dòng, không phải nguyên bài tập tính điểm trung bình cả lớp — cắt xuống đúng phần gây lỗi, giữ nguyên phần còn lại của chương trình chỉ làm người đọc mất công tìm.

Output thật, chép nguyên văn:

Traceback (most recent call last):
  File "tinh_diem.py", line 2, in <module>
    trung_binh = diem / 2
                 ~~~~~^~~
TypeError: unsupported operand type(s) for /: 'str' and 'int'

Kết quả mong đợi: in ra 4.0, tức điểm trung bình của một điểm số duy nhất.

Giả thuyết đã thử: đã thử bỏ dấu ngoặc kép quanh 8, đổi thành diem = 8 — lúc đó chương trình chạy đúng. Nên nghi ngờ nằm ở chỗ giá trị đang là chuỗi thay vì số, nhưng chưa biết vì sao dữ liệu vào lại là chuỗi trong bài gốc.

Chỉ với bốn phần này, người đọc — hoặc chính bạn đọc lại — thấy ngay hướng đi tiếp theo: lần ngược xem giá trị chuỗi đó đến từ đâu, nhiều khả năng là từ input() chưa đổi kiểu.

4. Thử đoán — output thật nghĩa là chép đủ

Đoạn code sau đang định in điểm của ba bạn trong lớp:

diem = [8, 9, 7]
for i in range(4):
    print(diem[i])

8
9
7
Traceback (most recent call last):
  File "in_diem.py", line 3, in <module>
    print(diem[i])
          ~~~~^^^
IndexError: list index out of range

5. Tới lượt bạn

Một bạn khác trong group cũng vừa đăng một câu hỏi tồi khác:

Code em chạy bị lỗi giữa chừng, ai chỉ em với, cảm ơn ạ.

Kèm theo là đoạn code bạn ấy dán nguyên cả bài tập dài bốn mươi dòng, không có output, không nói kết quả đang mong đợi là gì. Lục lại, bạn ấy tìm được đúng đoạn gây lỗi:

diem = [8, 9, 7]
tong = sum(diem)
so_ban = input("Nhap so ban: ")
trung_binh = tong / so_ban
print(trung_binh)

Viết lại câu hỏi này theo đúng khuôn bốn thành phần, dán nhãn từng phần như mục 3 vừa làm — dùng đúng đoạn code trên. Viết ra bản của bạn trước khi mở đáp án mẫu bên dưới; trước khi coi là xong, tự hỏi: đoạn code này có còn cắt được ngắn hơn mà vẫn giữ đúng lỗi không?

Nhap so ban: 3
Traceback (most recent call last):
  File "diem_trung_binh.py", line 4, in <module>
    trung_binh = tong / so_ban
                 ~~~~~^~~~~~~~
TypeError: unsupported operand type(s) for /: 'int' and 'str'

6. Bẫy thường gặp

7. 📚 Đào sâu

8. Liên hệ các bài khác

• Bài 1 — Ba loại lỗi — biết lỗi thuộc loại nào giúp bạn viết đúng phần "output thật": lỗi cú pháp và lỗi lúc chạy có traceback để chép, còn lỗi logic thì "output thật" là kết quả sai bạn nhận được, không phải một traceback.
• Bài 2 — Đọc thông báo lỗi — đọc đúng traceback là điều kiện để bạn chép đúng phần gây lỗi vào câu hỏi, thay vì chép nhầm dòng.
• Bài 3 — Sửa bằng giả thuyết — "giả thuyết đã thử" trong câu hỏi ở bài này chính là một vòng của quy trình bạn học ở bài đó, dừng lại đúng lúc cần hỏi thêm người khác.
• Bài 5 — Mini challenge — nơi bạn luyện lại cả bốn kỹ năng của module này trên cùng một đoạn code.

9. Tóm tắt

• Coi lần kẹt tiếp theo là tín hiệu chuyển sang quy trình thoát kẹt, không phải tín hiệu bạn thiếu năng lực — bước cuối của quy trình đó là viết một câu hỏi đủ để người khác trả lời được.
• Tiêu chí dừng thử sau hai mươi phút là "vùng nghi ngờ có thu hẹp không", không phải đồng hồ đã chạy đủ giờ.
• Trước khi gõ nút gửi, tự kiểm đủ bốn thành phần bằng cách đọc lại từng phần một — thiếu phần nào thì người đọc, hay chính bạn, không đủ dữ kiện để trả lời.
• Cắt code xuống mức tối thiểu vẫn phải giữ đúng lỗi — cắt quá tay làm lỗi biến mất, cắt chưa đủ thì người đọc lạc giữa code không liên quan.
• Nên viết đủ bốn phần ngay cả khi không định hỏi ai — chỉ riêng việc ép mình viết ra thường đã đủ để tự tìm ra đáp án.

10. Tự kiểm tra

Bài tiếp theo: Mini challenge — Spot the bug