A debug mind

Là một lập trình viên, công việc chính của tôi là ngồi viết code và sửa lỗi (fix bug). Fix bug là một trong những công việc chiếm khá nhiều thời gian của lập trình viên và chúng tôi vẫn thường nói đùa nhau: còn bug là còn sống. Có những lỗi tôi chỉ cần ngồi một lúc là biết nguyên nhân do đâu, nhưng có những lúc ngồi tìm hoài không thấy lỗi. Những lúc như vậy, tôi thường tỏ ra nản, không muốn dò lỗi nữa và cho rằng lỗi đó thật vô lý. Nhưng thật may mắn, vì trên tôi, là những người anh có nhiều kinh nghiệm lập trình. Sau vài lần được các anh trợ giúp tìm lỗi, tìm ra sự có lý của các lỗi đó, thì tôi đúc rút ra một vài điều như sau:

1. Nếu đó là lỗi thật sự từ phía phần mềm, thì lỗi đó chắc chắn hợp lý bởi vì bất kì thứ gì tồn tại đều hợp lý. Khi đã có lỗi xảy ra, thì chắc chắn là do một nguyên nhân nào đó, đó không thể là một điều vô lý. Việc của chúng ta là đi tìm xem nguyên nhân đó là gì.
2. Có 2 nhóm nguyên nhân chính khiến chúng ta gặp lỗi:
   • code của chính bản thân chúng ta: nhiều khi chúng ta cứ đinh ninh rằng code của chúng ta không sai, … cho đến khi tự chúng ta hoặc người khác tìm ra được lỗi sai đó.
   • Chúng ta không làm chủ, không hiểu được những công nghệ mà chúng ta sử dụng: việc viết một phần mềm cần sử dụng nhiều công nghệ, mà phần lớn những người lập trình viên như chúng ta không hoàn toàn hiểu rõ, ví dụ: bản thân ngôn ngữ lập trình, các thư viện và framework bên thứ ba, hệ điều hành hay môi trường sử dụng của phần mềm đó.

Nếu may mắn, bạn phán đoán đúng được lỗi có thể xảy ra do đâu thì quá trình debug có thể sẽ mất ít thời gian hơn. Nhưng nếu bạn không thể tái tạo lại lỗi hoặc nhìn thấy lỗi mà dò mãi không ra thì hãy nhớ đến 2 điều trên và bắt tay vào xem lại từng dòng code của bạn, thay vì cứ ngồi ngẩn ngơ với cái suy nghĩ: “lỗi này thật vô lý”.