WEBVTT 1 00:00:00.830 --> 00:00:03.240 So we talked about problem solving, 2 00:00:03.240 --> 00:00:07.720 which is a very important skill of any software developer. 3 00:00:07.720 --> 00:00:09.530 Now, another extremely important 4 00:00:09.530 --> 00:00:12.070 developer skill is debugging, 5 00:00:12.070 --> 00:00:15.710 which means to find and fix errors. 6 00:00:15.710 --> 00:00:19.010 So let's finish this section by talking about debugging 7 00:00:19.010 --> 00:00:22.043 to make you ready for the rest of the course ahead. 8 00:00:23.490 --> 00:00:26.270 So first of all, as you might already know, 9 00:00:26.270 --> 00:00:29.790 a software bug is a defect or a problem 10 00:00:29.790 --> 00:00:32.110 in a computer program. 11 00:00:32.110 --> 00:00:36.270 So basically, any unexpected or unintended behavior 12 00:00:36.270 --> 00:00:39.340 of a program is called a bug. 13 00:00:39.340 --> 00:00:43.370 And the actual term bug was coined in the 1940s 14 00:00:43.370 --> 00:00:46.580 when this real bug was causing an error 15 00:00:46.580 --> 00:00:47.923 in Harvard's computer. 16 00:00:48.780 --> 00:00:52.150 Now, there are many reasons for bugs in programs, 17 00:00:52.150 --> 00:00:54.550 but what matters here is that bugs 18 00:00:54.550 --> 00:00:58.640 are a completely normal part of software development, 19 00:00:58.640 --> 00:01:00.280 because we are humans, 20 00:01:00.280 --> 00:01:02.950 and humans make mistakes. 21 00:01:02.950 --> 00:01:06.870 In fact, every complex application contains bugs, 22 00:01:06.870 --> 00:01:09.940 which sometimes go undiscovered for years 23 00:01:09.940 --> 00:01:13.790 and can cause security holes or other problems. 24 00:01:13.790 --> 00:01:17.300 So really, don't feel bad if you introduce bugs 25 00:01:17.300 --> 00:01:18.560 in your own count. 26 00:01:18.560 --> 00:01:21.893 We all do it, even the most expert programmers. 27 00:01:22.780 --> 00:01:27.300 Now luckily, not all bugs cause huge security holes. 28 00:01:27.300 --> 00:01:30.090 In fact, many bugs are quite small 29 00:01:30.090 --> 00:01:32.200 and simple to discover. 30 00:01:32.200 --> 00:01:34.600 So let's see a simple example. 31 00:01:34.600 --> 00:01:37.240 Remember in our previous example, 32 00:01:37.240 --> 00:01:40.030 the goal was to reverse whatever was passed 33 00:01:40.030 --> 00:01:41.690 into the function. 34 00:01:41.690 --> 00:01:45.170 So let's say we finished writing the reverse function, 35 00:01:45.170 --> 00:01:49.400 and call it with this array and get this result. 36 00:01:49.400 --> 00:01:52.840 But clearly something is wrong here, right? 37 00:01:52.840 --> 00:01:55.970 The return value looks scrambled, 38 00:01:55.970 --> 00:01:58.370 but not reversed at all. 39 00:01:58.370 --> 00:02:01.310 So this means that we must have a bug somewhere 40 00:02:01.310 --> 00:02:04.490 in our reverse function, okay? 41 00:02:04.490 --> 00:02:07.840 To fix this, we use a process called debugging, 42 00:02:07.840 --> 00:02:10.800 which is essentially finding, fixing, 43 00:02:10.800 --> 00:02:12.760 and then preventing bugs. 44 00:02:12.760 --> 00:02:14.453 So let's see how that works. 45 00:02:15.690 --> 00:02:19.160 So the first step is to actually become aware 46 00:02:19.160 --> 00:02:21.310 that there is some kind of bug, 47 00:02:21.310 --> 00:02:24.220 because as I said, in a large application, 48 00:02:24.220 --> 00:02:28.130 bugs can actually go undiscovered for years. 49 00:02:28.130 --> 00:02:30.450 Now, discovering bugs usually happens 50 00:02:30.450 --> 00:02:34.580 during development using automated testing software 51 00:02:34.580 --> 00:02:37.570 or user reports during production. 52 00:02:37.570 --> 00:02:40.500 And bugs that are identified during production 53 00:02:40.500 --> 00:02:42.080 are the worst bugs, 54 00:02:42.080 --> 00:02:44.620 because it means that they went undiscovered 55 00:02:44.620 --> 00:02:46.830 during development and are now affecting 56 00:02:46.830 --> 00:02:49.730 real users of our application. 57 00:02:49.730 --> 00:02:51.900 So that's why it's really important 58 00:02:51.900 --> 00:02:53.950 to identify bugs early, 59 00:02:53.950 --> 00:02:57.150 for example, using automated tests. 60 00:02:57.150 --> 00:02:59.460 Now, while identifying the bug, 61 00:02:59.460 --> 00:03:02.150 sometimes we also need to take into consideration 62 00:03:02.150 --> 00:03:04.850 the context in which the bug happened. 63 00:03:04.850 --> 00:03:07.570 For example, certain bugs might only happen 64 00:03:07.570 --> 00:03:08.960 in a certain browser, 65 00:03:08.960 --> 00:03:11.983 or only for certain users, for some reason. 66 00:03:12.930 --> 00:03:15.660 Next, once we know there is a bug, 67 00:03:15.660 --> 00:03:19.290 we need to go into our code and find the bug. 68 00:03:19.290 --> 00:03:22.650 We need to isolate where exactly it's happening, 69 00:03:22.650 --> 00:03:25.310 and we can do that using the developer console 70 00:03:25.310 --> 00:03:26.363 that we already know. 71 00:03:27.210 --> 00:03:29.490 However, that only works for small bugs 72 00:03:29.490 --> 00:03:32.430 and simple code where we have a good idea 73 00:03:32.430 --> 00:03:35.010 where the bug might be located. 74 00:03:35.010 --> 00:03:36.800 But if the code is more complex 75 00:03:36.800 --> 00:03:40.060 and we have no idea where the bug might be, 76 00:03:40.060 --> 00:03:42.920 then we need to use a debugger software. 77 00:03:42.920 --> 00:03:45.570 And I will show you how that works in the next video 78 00:03:45.570 --> 00:03:47.830 because it's really important for developer 79 00:03:47.830 --> 00:03:49.823 to be able to use a debugger. 80 00:03:50.740 --> 00:03:54.270 Anyway, once we know where the bug is located, 81 00:03:54.270 --> 00:03:58.800 we can finally fix it so we can correct the bug. 82 00:03:58.800 --> 00:04:01.790 And this is probably the easiest part. 83 00:04:01.790 --> 00:04:03.960 So essentially, all we need to do 84 00:04:03.960 --> 00:04:08.320 is to replace the existing, so the wrong solution, 85 00:04:08.320 --> 00:04:12.620 with a new correct solution that actually works. 86 00:04:12.620 --> 00:04:15.670 As a final step, we should then prevent this bug 87 00:04:15.670 --> 00:04:19.030 from ever happening again in our code base. 88 00:04:19.030 --> 00:04:21.630 For example, we can search our project 89 00:04:21.630 --> 00:04:24.280 for the same bug in similar code, 90 00:04:24.280 --> 00:04:26.580 like in a similar function. 91 00:04:26.580 --> 00:04:29.250 It's totally possible that we did the same mistake 92 00:04:29.250 --> 00:04:30.900 twice in our code, 93 00:04:30.900 --> 00:04:32.200 and if that's the case, 94 00:04:32.200 --> 00:04:35.010 we must fix the bug everywhere. 95 00:04:35.010 --> 00:04:37.710 A more advanced way of preventing bugs 96 00:04:37.710 --> 00:04:40.980 is to write tests using testing software. 97 00:04:40.980 --> 00:04:43.360 And I might add a bonus section on testing 98 00:04:43.360 --> 00:04:45.530 to the course at some point 99 00:04:45.530 --> 00:04:47.790 because this is actually an important part 100 00:04:47.790 --> 00:04:49.780 of software development. 101 00:04:49.780 --> 00:04:51.610 Okay, and that's it. 102 00:04:51.610 --> 00:04:55.170 That's a broad overview of debugging in programming. 103 00:04:55.170 --> 00:04:57.830 And we really just scratched the surface here, 104 00:04:57.830 --> 00:05:00.640 because you're still at the beginning of the journey. 105 00:05:00.640 --> 00:05:02.653 And so this is just an introduction. 106 00:05:03.510 --> 00:05:06.983 Anyway, let's now fix some bugs in the next video.