Cách đây vài tháng, mình có viết 1 bài để chửi thực trạng học lập trìnhcủa các thanh niên hiện nay. Ngoại trừ một số câu hỏi bài tập, hoặc vấn đề công nghệ, phần nhiều các câu hỏi là “gặp lỗi không biết sửa”. Qua đó, có thể thấy các bạn sinh viên năm 2 năm 3 hoặc mới ra trường vẫn còn thiếu kĩ năng debug.
Thôi, các cụ có câu là “vừa đấm vừa xoa”, chửi sướng mồm rồi thì bây giờ viết một bài chia sẻ những kinh nghiệm để debug và đặt câu hỏi hiệu quả hơn đây. Mỗi khi thấy ai hỏi bài, nhờ sửa lỗi các bạn cứ share bài viết này để giúp ích cho người ta nhé.
Trời đã sinh dev sao còn sinh bug?
Người ta thường bảo là developer và QA (tester) là kẻ thù không đội trời chung, một bên ráng giấu bug còn một bên ráng chạy chương trình để moi bug. Tuy nhiên, sự thật không phải vậy. Cả dev và QA đều có kẻ thù chung là bug.
Thế mới có câu chuyện rằng: Một chàng developer gặp phải con bug rất khôn, lúc ẩn lúc hiện. Chàng phải OT hết cả tuần lễ để tìm bug, không có thời gian dắt gấu đi chơi nên gấu bỏ đi theo người khác. Uất hận, chàng ngửa mặt lên trời than “Trời đã sinh dev sao còn sinh bug”, sau đó hộc máu mà chết.
Thuở mới học lập trình, ta thường nghĩ rằng code là chuyện khó, sửa lỗi là chuyện dễ. Bắt đầu lập trình mới biết là thời gian debug đôi khi còn nhiều hơn thời gian viết code. Thế nhưng, trường đại học lại chỉ hướng dẫn học sinh viết code chứ không bao giờ cách debug. Điều này dẫn tới việc nhiều bạn gặp lỗi nhưng không biết cách tìm lỗi, không biết cách sửa.
Ở phần dưới, mình sẽ chia sẻ những bí kíp tìm lỗi từ sơ cấp đến cao cấp, cùng những điều cần lưu ý để đặt câu hỏi hiệu quả.
Quyển thứ nhất (sơ cấp) – Lỗi cú pháp
Đây là các lỗi hay gặp khi mới học lập trình, viết sai cú pháp nên chương trình không build được: thiếu mở đóng ngoặc, nhầm dấu bằng, thiếu chấm phẩy.
Cách giải quyết: dùng IDE xịn (Visual Studio, Eclipse, Atom). Các IDE này đều hỗ trợ nhắc lỗi cú pháp (Chỉ cần các bạn chịu khó đọc error message bằng tiếng Anh là được). Các lỗi này chỉ cần code nhiều là quen, hầu như đi làm sẽ hết bị. Bạn có thể tập một số thói quen như: Khi mở ngoặc nhớ đóng ngoặc, cuối câu lệnh phải thêm chấm phẩy.
Quyển thứ hai (trung cấp) – Exception
Sau khi sửa các lỗi cú pháp, chương trình đã build được, nhưng khi chạy lại crash hoặc quăng Exception. Exception hay gặp nhất làNullPointerException, khi bạn muốn truy cập vào một biến có giá trị null.
Các lỗi này cũng không quá khó xử lý. Chỉ cần đọc tên Exception + message kèm theo là bạn có thể hiểu được nguyên nhân gây lỗi. Tiếp theo, hãy copy tên Exception và message vào Google, câu trả lời thường sẽ có ở một vài link đầu tiên.
Quyển thứ ba (cao cấp) – Lỗi framework và logic
Đây thường là những lỗi phức tạp, chương trình chạy sai mà không báo lỗi hay quăng Exception gì. Ví dụ, lỗi mà bạn nào cũng gặp khi mới học là viết = thay cho ==, chương trình chạy sai mà không rõ lỗi là gì.
|
1
2
3
|
if (x=3) {// Do something} |
Các lỗi này thường khó sửa vì bạn không biết nguyên nhân gây lỗi nên không biết sửa. Với những lỗi dạng này, trước tiên bạn cần xác định:
- Code của mình sẽ chạy các bước nào, gọi những hàm nào
- Kết quả đúng mà các hàm nên return là gì
- Kết quả thực sự các hàm return là gì
- Kết quả nào bị sai? Hàm nào return nó? Nguyên nhân sai là gì?
- Xác định hàm chạy sai, lặp lại bước 1.
Nếu chưa biết debug hãy in ra toàn bộ các giá trị và kiểm xem có giá trị nào sai hay không? Khi đã quen, bạn chỉ cần đặt breakpoint, cho chương trình chạy từng dòng lệnh và kiểm tra giá trị của từng biến.
Sau khi làm rõ những điều nói trên, nhiều khả năng bạn đã tìm được câu trả lời cho mình. Nếu không tìm được hàm gây lỗi, lục tung Google nhưng không tìm ra nguyên nhân hay cách sửa, bạn sẽ phải dùng đến cách cuối cùng: Vác đi hỏi.
Trong các hệ thống lớn và phức tạp, việc debug và tìm lỗi trở nên khó hơn rất nhiều. Mình sẽ có 1 bài viết chuyên sâu hơn về chuyện này.
Tàn quyển – Làm sao đặt câu hỏi một cách hiệu quả?
Đầu tiên, hãy đặt mình vào vị trí người được hỏi, liệu họ đọc câu hỏi có hiểu gì không. Nhiều bạn cứ hỏi chung chung kiểu: Code không chạy được!! Thánh cũng chả hiểu code của bạn tại sao lại không chạy được. Làm rõ điều cần hỏi là bạn đã trả lời được 50% câu hỏi rồi.
Khi bạn vác một câu hỏi lên stackoverflow, bạn thường được yêu cầu là: Tạo 1 fiddle cho câu hỏi, hoặc chỉ post đoạn code gây lỗi lên. Hãy tập thói quen này trước khi đi hỏi: Xác định đoạn code gây bug, tách riêng nó ra, cố gắng tái tạo lại bug. Việc xác định được đoạn code gây bug là đã giải quyết 50% vấn đề rồi, có khi xác định xong là bạn sửa được bug luôn, chẳng cần phải đi hỏi nữa.
Hãy nhớ một điều, luôn luôn google và tìm hiểu trước khi đặt câu hỏi. Người được hỏi thường rất sẵn lòng giúp đỡ, nhưng họ sẽ rất bực mình nếu bạn hỏi những câu đơn giản mà chỉ cần 30s google là ra. Việc không chịu tìm hiểu, google trước khi hỏi chứng tỏ bạn lười và không tôn trọng thời gian của người được hỏi.
Lời kết
Kĩ năng debug cũng như kĩ năng code đều cần có thời gian rèn luyện mới có thể thành thục. Do đó, đừng buồn hay nản lòng khi bạn tốn quá nhiều thời gian để fix lỗi. Qua một thời gian bạn sẽ quen dần và nhanh hơn thôi. Nhớ nhé, phải thường xuyên luyện tập code và tự debug thì mới nâng cao được khả năng code lẫn kĩ năng debug nhé.
Đã nói ở phần trên rồi, nhưng mình vẫn nhắc lại thêm lần nữa. Thay vì cứ gặp khó khăn là vác đi hỏi lung tung, nhớ Google 7 lần trước khi hỏi. Về lâu dài, việc này sẽ nâng cao khả năng tìm lỗi và debug của bạn đấy. Đừng để tới lúc đi làm, cứ bí là phải lên Facebook hỏi hoặc quay sang hỏi đồng nghiệp nhé =))).
Một số resource nên tham khảo:
- https://www.quora.com/How-do-programmers-code-quickly
- https://blog.codeunion.io/2014/09/03/teaching-novices-how-to-debug-code/
- Sách Debug It! Find, Repair and Prevent Bugs in Your Code
