3.2. How to Avoid Debugging - làm sao để tránh lỗi.
Perhaps the most important lesson in debugging is that it is largely avoidable – if you work carefully.
- Start Small This is probably the single biggest piece of advice for programmers at every level. Of course its tempting to sit down and crank out an entire program at once. But, when the program – inevitably – does not work then you have a myriad of options for things that might be wrong. Where to start? Where to look first? How to figure out what went wrong? I’ll get to that in the next section. So, start with something really small. Maybe just two lines and then make sure that runs ok. Hitting the run button is quick and easy, and gives you immediate feedback about whether what you have just done is ok or not. Another immediate benefit of having something small working is that you have something to turn in. Turning in a small, incomplete program, is almost always better than nothing.
1. Bắt đầu từ việc nhỏ: Đây có lẽ là lời khuyên tốt nhất cho các lập trình viên ở mọi cấp độ. Tất nhiên cũng có phương án là ngồi và làm toàn bộ chương trình trong 1 lúc. Nhưng khi chương trình - chắc chắn - không làm việc thì sẽ rất khó tìm được lỗi sai. Bắt đầu từ đâu? Nơi nào để tìm đầu tiên> Làm thế nào để tìm ra chỗ sai? Chính vì điều này chúng ta nên làm từng bước nhỏ 1. Đảm bảo từ 2 dòng chạy oki, chúng ta chạy thử để xem mình làm chuẩn chưa? Ít nhất khi chúng ta hoàn thành các việc (ctrinh nhỏ) trước thì sẽ tốt hơn là chưa làm gì
- Keep it working Once you have a small part of your program working the next step is to figure out something small to add to it. If you keep adding small pieces of the program one at a time, it is much easier to figure out what went wrong, as it is most likely that the problem is going to be in the new code you have just added. Less new code means its easier to figure out where the problem is.
3. tiếp tục làm việc: Một khi bạn làm cho một phần nhỏ của chương trình làm việc thì bước tiếp theo là phỏng đoán những thứ nhỏ để thêm vào nó. Nếu bạn thêm những miếng nhỏ của chương trình vòa cùng 1 lúc, nó sẽ dễ dàng để tìm ra cái gì sai, giống như việc vấn đề nằm ở chỗ đoạn code mà bạn vừa thêm vào. Giới hạn lỗi trong những mã mới thêm vào sẽ giúp chung ta dễ tìm ra vấn đề hơn.
This notion of Get something working and keep it working is a mantra that you can repeat throughout your career as a programmer. It’s a great way to avoid the frustrations mentioned above. Think of it this way. Every time you have a little success, your brain releases a tiny bit of chemical that makes you happy. So, you can keep yourself happy and make programming more enjoyable by creating lots of small victories for yourself.
Ok, let’s look at an example. Let’s solve the problem posed in question 3 at the end of the Simple Python Data chapter. Ask the user for the time now (in hours 0 - 23), and ask for the number of hours to wait. Your program should output what the time will be on the clock when the alarm goes off.
So, where to start? The problem requires two pieces of input from the user, so let’s start there and make sure we can get the data we need.
(db_ex3_1)
So far so good. Now let’s take the next step. We need to figure out what the time will be after waiting
wait_time
number of hours. A good first approximation to that is to simply add wait_time
to current_time
and print out the result. So lets try that.
(db_ex3_2)
Hmm, when you run that example you see that something funny has happened.
debug-2-1: Which of the following best describes what is wrong with the previous example?
This error was probably pretty simple to spot, because we printed out the value of
final_time
and it is easy to see that the numbers were just concatenated together rather than added. So what do we do about the problem? We will need to convert both current_time
and wait_time
to int
. At this stage of your programming development, it can be a good idea to include the type of the variable in the variable name itself. So let’s look at another iteration of the program that does that, and the conversion to integer.
(db_ex3_3)
Now, thats a lot better, and in fact depending on the hours you chose, it may be exactly right. If you entered 8 for the current time and 5 for the wait time then 13 is correct. But if you entered 17 (5pm) for the hours and 9 for the wait time then the result of 26 is not correct. This illustrates an important aspect of testing, which is that it is important to test your code on a range of inputs. It is especially important to test your code on boundary conditions. In this case you would want to test your program for hours including 0, 23, and some in between. You would want to test your wait times for 0, and some really large numbers. What about negative numbers? Negative numbers don’t make sense, but since we don’t really have the tools to deal with telling the user when something is wrong we will not worry about that just yet.
So finally we need to account for those numbers that are bigger than 23. For this we will need one final step, using the modulo operator.
(db_ex3_4)
Of course even in this simple progression, there are other ways you could have gone astray. We’ll look at some of those and how you track them down in the next section
giải thích ví dụ:
Trong cái ví dụ này chúng ta cần lưu ý là số giờ tổng chia cho 24h (của 1 ngày) được số dư ra sẽ lại bắt đầu 1 chu kỳ mới của ngày mới.
Ờ chia lấy số dư (%) nhé.
Tóm lại bài này cần lưu ý việc kiểm tra từng đoạn code nhỏ và phải chú ý khi đối phó với những giá trị nhập sai từ phía người dùng. Phải đặt ra các giả thiết nhằm đảm bảo rằng chương trình không phát sinh lỗi.
giải thích ví dụ:
Trong cái ví dụ này chúng ta cần lưu ý là số giờ tổng chia cho 24h (của 1 ngày) được số dư ra sẽ lại bắt đầu 1 chu kỳ mới của ngày mới.
Ờ chia lấy số dư (%) nhé.
Tóm lại bài này cần lưu ý việc kiểm tra từng đoạn code nhỏ và phải chú ý khi đối phó với những giá trị nhập sai từ phía người dùng. Phải đặt ra các giả thiết nhằm đảm bảo rằng chương trình không phát sinh lỗi.
Nhận xét
Đăng nhận xét