diff options
| author | Nguyễn Gia Phong <mcsinyx@disroot.org> | 2020-05-24 16:34:31 +0700 |
|---|---|---|
| committer | Nguyễn Gia Phong <mcsinyx@disroot.org> | 2020-05-24 16:34:31 +0700 |
| commit | b2d80610db6beda38573890ed169815e495bc663 (patch) | |
| tree | 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P4L5 Software Refactoring Subtitles | |
| parent | 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff) | |
| download | cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz | |
[usth/ICT2.7] Engineer software
Diffstat (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles')
25 files changed, 3279 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..bab48c0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,71 @@ +1 +00:00:00,140 --> 00:00:02,220 +In the previous lesson, we discussed agile + +2 +00:00:02,220 --> 00:00:05,689 +software development. Its principles and practices. And two + +3 +00:00:05,689 --> 00:00:10,060 +specific agile processes. XP and Scrub. In + +4 +00:00:10,060 --> 00:00:12,230 +this lesson, we will introduce a practice that + +5 +00:00:12,230 --> 00:00:15,020 +is of fundamental importance in the context + +6 +00:00:15,020 --> 00:00:20,120 +of agile software development. Software refactoring. Software refactoring + +7 +00:00:20,120 --> 00:00:22,030 +is the process of taking a program and + +8 +00:00:22,030 --> 00:00:25,040 +transforming it to make it better. That is, + +9 +00:00:25,040 --> 00:00:27,240 +to make it easier to understand, make it + +10 +00:00:27,240 --> 00:00:29,880 +more maintainable, and in general to improve its + +11 +00:00:29,880 --> 00:00:34,300 +design. Specifically, we will discuss what the refactoring + +12 +00:00:34,300 --> 00:00:37,680 +is and why it is important? When to perform + +13 +00:00:37,680 --> 00:00:40,980 +refactoring, and when not to perform refactoring? And + +14 +00:00:40,980 --> 00:00:44,520 +how to perform refactoring in a fully automated way, + +15 +00:00:44,520 --> 00:00:47,293 +using tools. We will also introduce the concept + +16 +00:00:47,293 --> 00:00:50,040 +of bad smells, where a bad smell, in software, + +17 +00:00:50,040 --> 00:00:53,323 +is the indication that there might be something wrong with + +18 +00:00:53,323 --> 00:00:56,890 +the code that might call for the application of refactoring. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt new file mode 100644 index 0000000..89f2722 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt @@ -0,0 +1,55 @@ +1 +00:00:00,080 --> 00:00:03,230 +So the resulting code will be like this. As you can see here, + +2 +00:00:03,230 --> 00:00:06,602 +now I don't have the conditionals any longer, but I just have a call to + +3 +00:00:06,602 --> 00:00:09,938 +this notEligibleForDisability method. And this makes the code so + +4 +00:00:09,938 --> 00:00:14,092 +much clearer, because if I just need to understand how disabilityAmount works, + +5 +00:00:14,092 --> 00:00:17,945 +I can clearly see there is an initial check that is actually checking whether + +6 +00:00:17,945 --> 00:00:22,030 +an employee's eligible for disabilities or not. And if the check is false, so + +7 +00:00:22,030 --> 00:00:26,180 +if the employee's eligible, then I'll just perform the rest of the computation. + +8 +00:00:26,180 --> 00:00:27,710 +Otherwise I'll simply return zero. + +9 +00:00:27,710 --> 00:00:30,500 +So if I don't need to understand the details of this check, + +10 +00:00:30,500 --> 00:00:33,630 +I can simply look at this method and understand it all. And if I need to look at + +11 +00:00:33,630 --> 00:00:36,990 +the details I can just go, and look at the implementation of this method, + +12 +00:00:36,990 --> 00:00:39,600 +and I will get exactly the same information that I have here. But I'm sort of + +13 +00:00:39,600 --> 00:00:43,220 +separating the concerns, and making the code overall more understandable, and + +14 +00:00:43,220 --> 00:00:46,160 +therefore more maintainable, which is the main goal of refactoring. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt new file mode 100644 index 0000000..ef89eb8 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt @@ -0,0 +1,263 @@ +1 +00:00:00,080 --> 00:00:02,740 +Let's now see a related refactoring, which is the + +2 +00:00:02,740 --> 00:00:06,200 +decompose conditional refactoring. What happens here is that in some + +3 +00:00:06,200 --> 00:00:08,980 +cases, the complexity of the conditional logic in a program + +4 +00:00:08,980 --> 00:00:12,040 +can make a method hard to read and understand. Specifically + +5 +00:00:12,040 --> 00:00:15,760 +we might have one or more particularly complex conditional + +6 +00:00:15,760 --> 00:00:18,580 +statements. And similar to what we discussed for the previous + +7 +00:00:18,580 --> 00:00:21,630 +refactoring, the conditional, if it's too complex, might tell you + +8 +00:00:21,630 --> 00:00:25,170 +what happens, but obscure why it happens. To address this + +9 +00:00:25,170 --> 00:00:27,520 +issue, you can do a similar thing to what we did in + +10 +00:00:27,520 --> 00:00:31,800 +the previous refactoring. You can transform the condition into a method and then + +11 +00:00:31,800 --> 00:00:35,260 +replace the condition with a call to that method. And if you give + +12 +00:00:35,260 --> 00:00:37,930 +the right name to the method, as we saw in the last example, + +13 +00:00:37,930 --> 00:00:41,730 +that can make the code much clearer and much easier to understand. In + +14 +00:00:41,730 --> 00:00:44,360 +addition here you can also do something else. Let's assume that those are + +15 +00:00:44,360 --> 00:00:47,430 +the then and else part of the conditional are complex. We can do + +16 +00:00:47,430 --> 00:00:50,180 +the same thing with them. So what we can do, we can modify + +17 +00:00:50,180 --> 00:00:53,570 +the then and else part of the conditional by extracting the corresponding + +18 +00:00:53,570 --> 00:00:57,070 +code, making also that one into a method, suitably naming the method, + +19 +00:00:57,070 --> 00:00:59,930 +and then having the call to the method only in the then + +20 +00:00:59,930 --> 00:01:03,540 +and else part of the conditional statement. So let's see how that works + +21 +00:01:03,540 --> 00:01:06,940 +with an example. Here we have the matter that computes some charge. + +22 +00:01:06,940 --> 00:01:10,350 +And it computes the charge based on some corrective uses of the date + +23 +00:01:10,350 --> 00:01:12,930 +that is provided as input, or it's imagined or is just, you + +24 +00:01:12,930 --> 00:01:15,410 +know, one of the fields in the class. So as you can see, + +25 +00:01:15,410 --> 00:01:18,140 +there is a conditional here that checks that if the + +26 +00:01:18,140 --> 00:01:21,535 +dates is before the beginning of the summer, so before summer + +27 +00:01:21,535 --> 00:01:25,180 +start. Or it's after the summer end. Then it compute + +28 +00:01:25,180 --> 00:01:29,152 +the charge using some winterRate. Otherwise, if we are in the + +29 +00:01:29,152 --> 00:01:32,288 +summer, it will compute the quantity, the charge using a + +30 +00:01:32,288 --> 00:01:35,440 +summerRate. And this is just a small example, so it might + +31 +00:01:35,440 --> 00:01:37,990 +not look that complex. But, you know, just project this on + +32 +00:01:37,990 --> 00:01:40,458 +more realistic code, on larger code. You can end up with + +33 +00:01:40,458 --> 00:01:43,656 +the conditions that are hard to understand. And even in this case, even + +34 +00:01:43,656 --> 00:01:45,944 +such a small piece of code, you have to kind of look at + +35 +00:01:45,944 --> 00:01:48,752 +the conditionals, figure out what does it mean for the date to be + +36 +00:01:48,752 --> 00:01:51,800 +before the summer start and after the summer end. We can make this much + +37 +00:01:51,800 --> 00:01:54,780 +clearer. So, how can we do it? By applying this refactoring as we + +38 +00:01:54,780 --> 00:01:56,190 +described. Let's see what happens when + +39 +00:01:56,190 --> 00:01:58,380 +I apply the decompose conditionals refactoring to + +40 +00:01:58,380 --> 00:02:01,530 +this method. The first thing I will do is to take this condition, + +41 +00:02:01,530 --> 00:02:05,640 +create a method that perform exactly the same check, give it a meaningful name. + +42 +00:02:05,640 --> 00:02:09,380 +In this case I called it notSummer, which is pretty self-explanatory, and then + +43 +00:02:09,380 --> 00:02:12,340 +replacing the condition with a call to that matter. As you can see + +44 +00:02:12,340 --> 00:02:15,230 +here, there's a clear improvement in the code, because here I just need + +45 +00:02:15,230 --> 00:02:17,810 +to look at this statement and I see right away that the check. What + +46 +00:02:17,810 --> 00:02:20,680 +the check is doing is just checking whether the date is in the + +47 +00:02:20,680 --> 00:02:24,320 +summer or not. So, much easier than having to interpret this condition. And + +48 +00:02:24,320 --> 00:02:26,910 +the second thing I do is to take the code that computes the + +49 +00:02:26,910 --> 00:02:28,600 +charge and also in this case, creating + +50 +00:02:28,600 --> 00:02:31,028 +suitable methods that compute the winterCharge and + +51 +00:02:31,028 --> 00:02:34,838 +the summerCharge. And I called them exactly winterCharge and summerCharge which + +52 +00:02:34,838 --> 00:02:38,278 +again is self explanatory. And then I replace this computation with + +53 +00:02:38,278 --> 00:02:40,710 +a call to that method. So again, when I look at + +54 +00:02:40,710 --> 00:02:43,280 +this code, I can clearly see that the charge is computed + +55 +00:02:43,280 --> 00:02:46,570 +using some sort of winterCharge calculation and then using some sort + +56 +00:02:46,570 --> 00:02:50,490 +of summerCharge calculation. And if I don't want to know how + +57 +00:02:50,490 --> 00:02:52,670 +this is exactly computed, that's all I need to know to + +58 +00:02:52,670 --> 00:02:56,100 +understand what this method does. Easier and faster than looking at + +59 +00:02:56,100 --> 00:02:57,970 +this method and figuring out what it does. And if + +60 +00:02:57,970 --> 00:02:59,950 +I need to look at the details, exactly like in the + +61 +00:02:59,950 --> 00:03:01,550 +previous case, I can just go and look at the + +62 +00:03:01,550 --> 00:03:04,170 +implementation of winterCharge and summerCharge. But I will be looking at + +63 +00:03:04,170 --> 00:03:06,980 +that in its specific context. So, without having to understand + +64 +00:03:06,980 --> 00:03:09,760 +everything at once. So in this way, you make it clear + +65 +00:03:09,760 --> 00:03:12,840 +both why you're doing something, because it is notSummer, and + +66 +00:03:12,840 --> 00:03:16,300 +what exactly you're doing. You're computing a winterCharge, or a summerCharge. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt new file mode 100644 index 0000000..ef89eb8 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt @@ -0,0 +1,263 @@ +1 +00:00:00,080 --> 00:00:02,740 +Let's now see a related refactoring, which is the + +2 +00:00:02,740 --> 00:00:06,200 +decompose conditional refactoring. What happens here is that in some + +3 +00:00:06,200 --> 00:00:08,980 +cases, the complexity of the conditional logic in a program + +4 +00:00:08,980 --> 00:00:12,040 +can make a method hard to read and understand. Specifically + +5 +00:00:12,040 --> 00:00:15,760 +we might have one or more particularly complex conditional + +6 +00:00:15,760 --> 00:00:18,580 +statements. And similar to what we discussed for the previous + +7 +00:00:18,580 --> 00:00:21,630 +refactoring, the conditional, if it's too complex, might tell you + +8 +00:00:21,630 --> 00:00:25,170 +what happens, but obscure why it happens. To address this + +9 +00:00:25,170 --> 00:00:27,520 +issue, you can do a similar thing to what we did in + +10 +00:00:27,520 --> 00:00:31,800 +the previous refactoring. You can transform the condition into a method and then + +11 +00:00:31,800 --> 00:00:35,260 +replace the condition with a call to that method. And if you give + +12 +00:00:35,260 --> 00:00:37,930 +the right name to the method, as we saw in the last example, + +13 +00:00:37,930 --> 00:00:41,730 +that can make the code much clearer and much easier to understand. In + +14 +00:00:41,730 --> 00:00:44,360 +addition here you can also do something else. Let's assume that those are + +15 +00:00:44,360 --> 00:00:47,430 +the then and else part of the conditional are complex. We can do + +16 +00:00:47,430 --> 00:00:50,180 +the same thing with them. So what we can do, we can modify + +17 +00:00:50,180 --> 00:00:53,570 +the then and else part of the conditional by extracting the corresponding + +18 +00:00:53,570 --> 00:00:57,070 +code, making also that one into a method, suitably naming the method, + +19 +00:00:57,070 --> 00:00:59,930 +and then having the call to the method only in the then + +20 +00:00:59,930 --> 00:01:03,540 +and else part of the conditional statement. So let's see how that works + +21 +00:01:03,540 --> 00:01:06,940 +with an example. Here we have the matter that computes some charge. + +22 +00:01:06,940 --> 00:01:10,350 +And it computes the charge based on some corrective uses of the date + +23 +00:01:10,350 --> 00:01:12,930 +that is provided as input, or it's imagined or is just, you + +24 +00:01:12,930 --> 00:01:15,410 +know, one of the fields in the class. So as you can see, + +25 +00:01:15,410 --> 00:01:18,140 +there is a conditional here that checks that if the + +26 +00:01:18,140 --> 00:01:21,535 +dates is before the beginning of the summer, so before summer + +27 +00:01:21,535 --> 00:01:25,180 +start. Or it's after the summer end. Then it compute + +28 +00:01:25,180 --> 00:01:29,152 +the charge using some winterRate. Otherwise, if we are in the + +29 +00:01:29,152 --> 00:01:32,288 +summer, it will compute the quantity, the charge using a + +30 +00:01:32,288 --> 00:01:35,440 +summerRate. And this is just a small example, so it might + +31 +00:01:35,440 --> 00:01:37,990 +not look that complex. But, you know, just project this on + +32 +00:01:37,990 --> 00:01:40,458 +more realistic code, on larger code. You can end up with + +33 +00:01:40,458 --> 00:01:43,656 +the conditions that are hard to understand. And even in this case, even + +34 +00:01:43,656 --> 00:01:45,944 +such a small piece of code, you have to kind of look at + +35 +00:01:45,944 --> 00:01:48,752 +the conditionals, figure out what does it mean for the date to be + +36 +00:01:48,752 --> 00:01:51,800 +before the summer start and after the summer end. We can make this much + +37 +00:01:51,800 --> 00:01:54,780 +clearer. So, how can we do it? By applying this refactoring as we + +38 +00:01:54,780 --> 00:01:56,190 +described. Let's see what happens when + +39 +00:01:56,190 --> 00:01:58,380 +I apply the decompose conditionals refactoring to + +40 +00:01:58,380 --> 00:02:01,530 +this method. The first thing I will do is to take this condition, + +41 +00:02:01,530 --> 00:02:05,640 +create a method that perform exactly the same check, give it a meaningful name. + +42 +00:02:05,640 --> 00:02:09,380 +In this case I called it notSummer, which is pretty self-explanatory, and then + +43 +00:02:09,380 --> 00:02:12,340 +replacing the condition with a call to that matter. As you can see + +44 +00:02:12,340 --> 00:02:15,230 +here, there's a clear improvement in the code, because here I just need + +45 +00:02:15,230 --> 00:02:17,810 +to look at this statement and I see right away that the check. What + +46 +00:02:17,810 --> 00:02:20,680 +the check is doing is just checking whether the date is in the + +47 +00:02:20,680 --> 00:02:24,320 +summer or not. So, much easier than having to interpret this condition. And + +48 +00:02:24,320 --> 00:02:26,910 +the second thing I do is to take the code that computes the + +49 +00:02:26,910 --> 00:02:28,600 +charge and also in this case, creating + +50 +00:02:28,600 --> 00:02:31,028 +suitable methods that compute the winterCharge and + +51 +00:02:31,028 --> 00:02:34,838 +the summerCharge. And I called them exactly winterCharge and summerCharge which + +52 +00:02:34,838 --> 00:02:38,278 +again is self explanatory. And then I replace this computation with + +53 +00:02:38,278 --> 00:02:40,710 +a call to that method. So again, when I look at + +54 +00:02:40,710 --> 00:02:43,280 +this code, I can clearly see that the charge is computed + +55 +00:02:43,280 --> 00:02:46,570 +using some sort of winterCharge calculation and then using some sort + +56 +00:02:46,570 --> 00:02:50,490 +of summerCharge calculation. And if I don't want to know how + +57 +00:02:50,490 --> 00:02:52,670 +this is exactly computed, that's all I need to know to + +58 +00:02:52,670 --> 00:02:56,100 +understand what this method does. Easier and faster than looking at + +59 +00:02:56,100 --> 00:02:57,970 +this method and figuring out what it does. And if + +60 +00:02:57,970 --> 00:02:59,950 +I need to look at the details, exactly like in the + +61 +00:02:59,950 --> 00:03:01,550 +previous case, I can just go and look at the + +62 +00:03:01,550 --> 00:03:04,170 +implementation of winterCharge and summerCharge. But I will be looking at + +63 +00:03:04,170 --> 00:03:06,980 +that in its specific context. So, without having to understand + +64 +00:03:06,980 --> 00:03:09,760 +everything at once. So in this way, you make it clear + +65 +00:03:09,760 --> 00:03:12,840 +both why you're doing something, because it is notSummer, and + +66 +00:03:12,840 --> 00:03:16,300 +what exactly you're doing. You're computing a winterCharge, or a summerCharge. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt new file mode 100644 index 0000000..07c93ed --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,100 --> 00:00:02,890 +We are now going to talk about the extract class refactoring. When a + +2 +00:00:02,890 --> 00:00:06,040 +softer system evolves, we might end up with classes that really do the + +3 +00:00:06,040 --> 00:00:09,210 +work of more than one class because we keep adding functionality to + +4 +00:00:09,210 --> 00:00:11,010 +the class. Therefore also they're too + +5 +00:00:11,010 --> 00:00:13,160 +big, too complicated. In particular, we might + +6 +00:00:13,160 --> 00:00:15,250 +end up with a class that is doing the work of two + +7 +00:00:15,250 --> 00:00:18,890 +classes. Typical examples are classes with many methods and quite a lot of + +8 +00:00:18,890 --> 00:00:22,520 +data, quite a lot of fields. In this case, it's normally good idea + +9 +00:00:22,520 --> 00:00:25,120 +to split the class into two, so what you will do, you will + +10 +00:00:25,120 --> 00:00:28,700 +create a new class and move there the relevant fields and methods from + +11 +00:00:28,700 --> 00:00:31,700 +the original class. So as to have two classes, each one implementing a + +12 +00:00:31,700 --> 00:00:34,900 +piece of the functionality. Let's look at an example. In this case we're + +13 +00:00:34,900 --> 00:00:38,850 +going to use a UML like representation for the class. We have this class Person + +14 +00:00:38,850 --> 00:00:41,769 +that ends up representing also a phone number. And imagine that we add + +15 +00:00:41,769 --> 00:00:44,500 +up these pieces, you know, a little bit at the time so we end + +16 +00:00:44,500 --> 00:00:47,430 +up with something that really is doing the job of the person and + +17 +00:00:47,430 --> 00:00:50,490 +of the phone number. So what we can do, we can actually do exactly + +18 +00:00:50,490 --> 00:00:52,650 +what we described here. We split this class + +19 +00:00:52,650 --> 00:00:55,470 +into a Person class, and the Phone Number class. + +20 +00:00:55,470 --> 00:00:57,440 +And then we establish a use relation, so we + +21 +00:00:57,440 --> 00:00:59,470 +have a reference of the phone number class into + +22 +00:00:59,470 --> 00:01:01,960 +this class. And by separating the telephone number behavior + +23 +00:01:01,960 --> 00:01:04,680 +into its own class, I once more improved the + +24 +00:01:04,680 --> 00:01:06,980 +structure of the code, because now I have classes + +25 +00:01:06,980 --> 00:01:09,070 +that are more cohesive, and do exactly one thing. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt new file mode 100644 index 0000000..a7f7f2f --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt @@ -0,0 +1,75 @@ +1 +00:00:00,150 --> 00:00:03,825 +This new refactoring called inline class is the reverse of the extract class + +2 +00:00:03,825 --> 00:00:06,700 +refactoring. And know that this is kind of a general situation in the + +3 +00:00:06,700 --> 00:00:09,500 +sense that it is often the case that the refactoring also has a + +4 +00:00:09,500 --> 00:00:11,480 +reverse refactoring that does exactly the + +5 +00:00:11,480 --> 00:00:13,202 +opposite. So basically, un-dos, in a sense, + +6 +00:00:13,202 --> 00:00:16,830 +the operation of the other refactoring. In this case, the motivation for the + +7 +00:00:16,830 --> 00:00:19,760 +refactoring is that during system evolution, we might end up with one or + +8 +00:00:19,760 --> 00:00:22,530 +more classes that do not do much. In this case what you want + +9 +00:00:22,530 --> 00:00:25,350 +to do is to take the class that is not doing that much and + +10 +00:00:25,350 --> 00:00:28,740 +move its features into another class. And then delete the original class. + +11 +00:00:28,740 --> 00:00:31,010 +So lets use an example similar to the one we've used for + +12 +00:00:31,010 --> 00:00:34,000 +the previous refactoring to illustrate how this works. Here we have in + +13 +00:00:34,000 --> 00:00:37,750 +this case, two classes, person and office. And the person class is + +14 +00:00:37,750 --> 00:00:40,720 +using the office class, but this latter class, the office class, only + +15 +00:00:40,720 --> 00:00:44,000 +contains a phone number. So it doesn't really do that much. What + +16 +00:00:44,000 --> 00:00:47,020 +we can do is therefore to fold the office class into the + +17 +00:00:47,020 --> 00:00:50,470 +person class, by simply moving its only field into the class. And so + +18 +00:00:50,470 --> 00:00:53,260 +the result will be this person class that also contains the information + +19 +00:00:53,260 --> 00:00:56,600 +about the office number, and overall a simpler design for the code. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt new file mode 100644 index 0000000..88769e0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt @@ -0,0 +1,163 @@ +1 +00:00:00,060 --> 00:00:02,406 +The next re-factoring which is also the last one that we'll + +2 +00:00:02,406 --> 00:00:05,640 +see, extract method is one of the most commonly used re-factoring. As + +3 +00:00:05,640 --> 00:00:09,080 +it is applicable in many, many situations. The starting point is + +4 +00:00:09,080 --> 00:00:12,720 +a method that is too long and contains cohesive code fragments, that + +5 +00:00:12,720 --> 00:00:16,180 +really serve a single very specific purpose. So we start from + +6 +00:00:16,180 --> 00:00:19,270 +a cohesive code fragment in a large method. What we can do + +7 +00:00:19,270 --> 00:00:22,370 +in this case, is to create a method using that code fragment. + +8 +00:00:22,370 --> 00:00:25,620 +And then replacing the code fragment with a call to that method. + +9 +00:00:25,620 --> 00:00:28,390 +Let's look at this with an example. Here over this method called + +10 +00:00:28,390 --> 00:00:31,070 +print owing, and what it does, imagine that it does a lot + +11 +00:00:31,070 --> 00:00:33,850 +of operations here that I'm just not listing, and then it's got + +12 +00:00:33,850 --> 00:00:37,620 +a set of print statements. That are just printing a lot of details + +13 +00:00:37,620 --> 00:00:41,280 +about the owing information. And then again, a lot of code after + +14 +00:00:41,280 --> 00:00:44,270 +that. So what I could do in this case to simplify. The + +15 +00:00:44,270 --> 00:00:47,940 +method is to transform this set of statements. They are cohesive in + +16 +00:00:47,940 --> 00:00:51,120 +the sense that they do just one thing, they just print these details + +17 +00:00:51,120 --> 00:00:53,890 +into a method, and then I had, replace the statements with a + +18 +00:00:53,890 --> 00:00:56,740 +call to that method. Which is actually something similar to what we did + +19 +00:00:56,740 --> 00:00:59,900 +as part of some the previous re-factoring's. Here I'm showing the result. + +20 +00:00:59,900 --> 00:01:02,770 +So here is the method that I extracted. As you can see. It + +21 +00:01:02,770 --> 00:01:05,790 +contains the code that was previously here. I give you the meaningful + +22 +00:01:05,790 --> 00:01:09,080 +name, I called it printDetails so it's clear what it does. And now + +23 +00:01:09,080 --> 00:01:12,820 +the print owning method is simpler. Because I still have the remaining code + +24 +00:01:12,820 --> 00:01:17,200 +the one I didn't touch. But now this potentially long list of details. + +25 +00:01:17,200 --> 00:01:20,560 +Of prints, of details is not replaced by a single method code. + +26 +00:01:20,560 --> 00:01:23,550 +So a gain similar to the previous refactorings that we saw. If + +27 +00:01:23,550 --> 00:01:26,370 +we just look at the printing method, it's very easy to figure + +28 +00:01:26,370 --> 00:01:29,490 +out what this part does. Oh, print some details. And once more I + +29 +00:01:29,490 --> 00:01:33,060 +really want to stress this. If you don't care about how, this + +30 +00:01:33,060 --> 00:01:36,350 +is implemented and knowing that this print some details is enough. Then + +31 +00:01:36,350 --> 00:01:38,980 +you're done. You don't need to understand anything more. It's clear, it's + +32 +00:01:38,980 --> 00:01:42,430 +self explanatory. And if you'll need to look at what print details does, + +33 +00:01:42,430 --> 00:01:44,390 +you just go and look at print details. And you look at + +34 +00:01:44,390 --> 00:01:47,280 +it in isolation. So it's easier to understand what this does without having + +35 +00:01:47,280 --> 00:01:49,640 +to think the rest of the code. So once more the color we + +36 +00:01:49,640 --> 00:01:52,740 +factor in is just to improve your design, made the code more readable + +37 +00:01:52,740 --> 00:01:56,020 +Make the code more maintainable. And also keep in mind all of these, + +38 +00:01:56,020 --> 00:01:59,080 +are kind of small examples. You also always have to think about the + +39 +00:01:59,080 --> 00:02:02,560 +effect that this can have on larger codebases. It can really improve a + +40 +00:02:02,560 --> 00:02:05,280 +lot. The understandabililty, and maintainability of + +41 +00:02:05,280 --> 00:02:07,220 +your code. So in general, it's design. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt new file mode 100644 index 0000000..0559c88 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt @@ -0,0 +1,599 @@ +1 +00:00:00,090 --> 00:00:03,110 +So now we saw, this set of re-factoring's. They're nice, but + +2 +00:00:03,110 --> 00:00:06,260 +how can we actually perform re-factoring's? In some cases you'll have to + +3 +00:00:06,260 --> 00:00:08,430 +do it by hand. And you'll do it in that case in + +4 +00:00:08,430 --> 00:00:10,880 +small steps, so that you can check at every step that you + +5 +00:00:10,880 --> 00:00:14,180 +didn't introduce any area. But there's also many cases in which at + +6 +00:00:14,180 --> 00:00:17,640 +least for the more standard re-factoring's, you can just apply, you can + +7 +00:00:17,640 --> 00:00:21,530 +just use a tool that actually supports re-factoring. I'm going to show + +8 +00:00:21,530 --> 00:00:24,550 +you how that works, into a specific ID, Eclipse through a demo. + +9 +00:00:26,120 --> 00:00:28,425 +To show you how Eclipse, can help in performing + +10 +00:00:28,425 --> 00:00:31,880 +re-factoring, in an automated way, I just opened the Eclipse + +11 +00:00:31,880 --> 00:00:35,050 +editor and I maximized it. So that we can look + +12 +00:00:35,050 --> 00:00:36,810 +at the code more clearly. And as you can see + +13 +00:00:36,810 --> 00:00:39,551 +here, I have this class. It's called Re-factorable, it's a + +14 +00:00:39,551 --> 00:00:43,550 +pretty indicative name. And what we're going to do, we're going to + +15 +00:00:43,550 --> 00:00:47,840 +try to apply the extract method re-factoring to this class. + +16 +00:00:47,840 --> 00:00:51,060 +And in particular, to parts of this print owing method. + +17 +00:00:51,060 --> 00:00:54,090 +So this is a matter than will print owing's, + +18 +00:00:54,090 --> 00:00:56,160 +as the name says. And it will do several things + +19 +00:00:56,160 --> 00:00:59,180 +such as, for example, printing a banner first, then + +20 +00:00:59,180 --> 00:01:03,650 +calculating the outstanding debts, and then printing some details. So + +21 +00:01:03,650 --> 00:01:06,980 +the starting point for an extract method re-fractoring, is + +22 +00:01:06,980 --> 00:01:10,650 +the identification of some cohesive code fragment. And here, for + +23 +00:01:10,650 --> 00:01:12,970 +instance, we can see that, if we can see there, + +24 +00:01:12,970 --> 00:01:16,350 +these three print statements. They are basically printing some banner, + +25 +00:01:16,350 --> 00:01:18,530 +for the method. And I also put a comment here + +26 +00:01:18,530 --> 00:01:21,160 +just to make that even more explicit. So this is a + +27 +00:01:21,160 --> 00:01:23,970 +perfect case in which we might want to just extract + +28 +00:01:23,970 --> 00:01:27,220 +this part, create an independent method, so that we can make + +29 +00:01:27,220 --> 00:01:31,410 +the code more readable and maintainable. So I select, the + +30 +00:01:31,410 --> 00:01:33,320 +part of the code, that I want to put in my + +31 +00:01:33,320 --> 00:01:37,080 +method. I invoke the contextual menu, and as you can see + +32 +00:01:37,080 --> 00:01:41,287 +there is a re-factor entry here. Here are some re-factoring's [UNKNOWN], + +33 +00:01:41,287 --> 00:01:45,039 +re-factoring's that I can apply, and I'm going to select extract + +34 +00:01:45,039 --> 00:01:48,120 +method. When I do that, Eclipse is going to ask me to + +35 +00:01:48,120 --> 00:01:51,610 +specify a method name. I'll just call this one print + +36 +00:01:51,610 --> 00:01:54,260 +banner. And as you can see, as soon as I do + +37 +00:01:54,260 --> 00:01:57,310 +that, Eclipse will show me the preview, for the method + +38 +00:01:57,310 --> 00:02:01,010 +that will be generated. I'm going to leave the access modifier. To + +39 +00:02:01,010 --> 00:02:03,290 +public and I'm not going to change anything else. So, + +40 +00:02:03,290 --> 00:02:07,760 +now when I click Ok. As you can see Eclipse modified + +41 +00:02:07,760 --> 00:02:10,669 +my code so that now I have the Print Banner method + +42 +00:02:10,669 --> 00:02:14,050 +down here that does exactly what that piece of code was doing + +43 +00:02:14,050 --> 00:02:16,090 +before. And I just have an invocation of the Print Banner + +44 +00:02:16,090 --> 00:02:19,440 +method, up here, where the code was before. And of course, this + +45 +00:02:19,440 --> 00:02:21,830 +is something that we could have done by hand. It's pretty + +46 +00:02:21,830 --> 00:02:25,480 +easy to do, but it's even easier, to do it using Eclipse's + +47 +00:02:25,480 --> 00:02:29,040 +capabilities. And this will become even more apparent, when we consider slightly + +48 +00:02:29,040 --> 00:02:32,866 +more complex case. So here, if we look at this piece of + +49 +00:02:32,866 --> 00:02:35,234 +code for instance, we can that see this code + +50 +00:02:35,234 --> 00:02:38,264 +prints some details, about the always. And the reason + +51 +00:02:38,264 --> 00:02:41,351 +why this case is likely more complicated, is because + +52 +00:02:41,351 --> 00:02:45,210 +this code needs to know about the value of outstanding. + +53 +00:02:45,210 --> 00:02:49,130 +And whereas that underscore name, is a member of + +54 +00:02:49,130 --> 00:02:51,150 +the class, and therefore will be available to the + +55 +00:02:51,150 --> 00:02:55,110 +method. Outstanding is a locker variable, so a method + +56 +00:02:55,110 --> 00:02:58,310 +different from print, oh it wouldn't know anything about outstanding. + +57 +00:02:58,310 --> 00:03:00,070 +So let's see what happens when we try to apply + +58 +00:03:00,070 --> 00:03:03,460 +a re-factoring for this code. So we go again here + +59 +00:03:03,460 --> 00:03:06,410 +to the re-factor menu, we select extract method, we will + +60 +00:03:06,410 --> 00:03:10,080 +pick a name again. So let's call it [SOUND] print details, + +61 +00:03:10,080 --> 00:03:12,660 +since this is what the code does. And as you + +62 +00:03:12,660 --> 00:03:17,270 +can see here, Eclipse was able to figure out, that outstanding + +63 +00:03:17,270 --> 00:03:20,290 +has to be a parameter, of this method. So if + +64 +00:03:20,290 --> 00:03:23,340 +you look at the signature here, this will be very clear. + +65 +00:03:23,340 --> 00:03:26,270 +So outstanding has to be passed to the matter because + +66 +00:03:26,270 --> 00:03:29,230 +it's a locker variable of the print owing method. so + +67 +00:03:29,230 --> 00:03:32,600 +it will not be visible to the other methods otherwise. + +68 +00:03:32,600 --> 00:03:34,990 +So since eclipse figured it out, all I have to do, + +69 +00:03:34,990 --> 00:03:37,630 +is to press Ok. And at this point what I + +70 +00:03:37,630 --> 00:03:41,280 +will have here is my new method, for in details + +71 +00:03:41,280 --> 00:03:45,140 +that takes outstanding as a parameter. And does exactly what + +72 +00:03:45,140 --> 00:03:48,880 +the code was doing before. And here, where the code was, + +73 +00:03:48,880 --> 00:03:51,630 +I will have my print details invocation, with outstanding + +74 +00:03:51,630 --> 00:03:54,930 +as a parameter. So now, let's continue to extract methods. + +75 +00:03:54,930 --> 00:03:58,470 +And let's look at a even more complex case. which + +76 +00:03:58,470 --> 00:04:01,550 +is, the one involving this piece of code. So this + +77 +00:04:01,550 --> 00:04:03,900 +piece of code, as you can see, will calculate + +78 +00:04:03,900 --> 00:04:07,820 +the value of the outstanding debt. Will calculate the owing's, + +79 +00:04:07,820 --> 00:04:09,600 +and the way in which it does that, is by + +80 +00:04:09,600 --> 00:04:14,080 +considering all the orders, that are part of this enumeration. + +81 +00:04:14,080 --> 00:04:16,519 +That is the declared here, and it will + +82 +00:04:16,519 --> 00:04:20,769 +compute for each one, of these orders, the amount, + +83 +00:04:20,769 --> 00:04:23,520 +and then added to outstanding. So what is the + +84 +00:04:23,520 --> 00:04:26,160 +additional complication here? Well, the additional complication here is + +85 +00:04:26,160 --> 00:04:29,520 +that this code needs to know, not only + +86 +00:04:29,520 --> 00:04:33,220 +about outstanding. It also needs to know, about this + +87 +00:04:33,220 --> 00:04:36,160 +enumeration, because this one is also a local variable. + +88 +00:04:36,160 --> 00:04:39,140 +And in addition to that, this code also has + +89 +00:04:39,140 --> 00:04:43,280 +some side effects. So outstanding, is modified as a + +90 +00:04:43,280 --> 00:04:46,600 +consequence of the execution of this code. So how can + +91 +00:04:46,600 --> 00:04:49,120 +we do that in the extracted method? Well lets + +92 +00:04:49,120 --> 00:04:51,000 +see what the clips will do and what the clips + +93 +00:04:51,000 --> 00:04:53,950 +will suggest. It will try to again re-factor this + +94 +00:04:53,950 --> 00:04:58,030 +code and extract the method. In this case as you + +95 +00:04:58,030 --> 00:05:01,160 +can see. The clips does two things. First of all, + +96 +00:05:01,160 --> 00:05:04,180 +it figures out as before, that there are some parameters, + +97 +00:05:04,180 --> 00:05:07,650 +that are needed for this method to operate correctly. The + +98 +00:05:07,650 --> 00:05:11,600 +enumeration e, as we said, and the outstanding variable. In + +99 +00:05:11,600 --> 00:05:14,880 +addition, if you look at the method signature Eclipse will + +100 +00:05:14,880 --> 00:05:17,490 +also figure out that this method has to return, a + +101 +00:05:17,490 --> 00:05:21,530 +double value. So what does this value correspond to? This + +102 +00:05:21,530 --> 00:05:24,700 +value corresponds to a new value of outstanding. So if + +103 +00:05:24,700 --> 00:05:27,490 +we, give a name to this method, so we just + +104 +00:05:27,490 --> 00:05:29,620 +use the name, [SOUND] that I put in the comment + +105 +00:05:29,620 --> 00:05:33,510 +over there. We click Ok, and this will create + +106 +00:05:33,510 --> 00:05:36,560 +a method by extracting the code. And here, where the + +107 +00:05:36,560 --> 00:05:39,100 +method used to be, we will have that the + +108 +00:05:39,100 --> 00:05:43,169 +value of outstanding is updated. Based on the return value + +109 +00:05:43,169 --> 00:05:46,260 +of calculate outstanding. So in the end if we + +110 +00:05:46,260 --> 00:05:48,730 +look at this code, you can see that if we + +111 +00:05:48,730 --> 00:05:51,980 +just focus, on this code it's very easy to + +112 +00:05:51,980 --> 00:05:55,150 +understand what it does. It prints the banner, it calculates + +113 +00:05:55,150 --> 00:05:59,180 +an outstanding value, and then it prints some details. And + +114 +00:05:59,180 --> 00:06:01,520 +in case we don't care, as I said before, about the + +115 +00:06:01,520 --> 00:06:04,840 +details of what these methods do, we're done. And if we + +116 +00:06:04,840 --> 00:06:07,740 +care about the details we can look at each matter individually. + +117 +00:06:07,740 --> 00:06:10,580 +And get exactly the same information that we got before, + +118 +00:06:10,580 --> 00:06:13,650 +in a sort of a separation of concerns kind of way, + +119 +00:06:13,650 --> 00:06:16,420 +by focusing on one problem at a time. So now let + +120 +00:06:16,420 --> 00:06:19,345 +me do one last thing. So let me modify the code, + +121 +00:06:19,345 --> 00:06:23,170 +slightly. So i'm going to go back, to the version of + +122 +00:06:23,170 --> 00:06:25,610 +the code before re-factoring. So this is what we had. + +123 +00:06:25,610 --> 00:06:32,480 +And I'm going to add, an additional variable here, [SOUND] called count, + +124 +00:06:32,480 --> 00:06:38,870 +which I initialize to zero. Here I'm going to increase, [SOUND] + +125 +00:06:38,870 --> 00:06:41,360 +the value of count at every iteration. And + +126 +00:06:41,360 --> 00:06:44,570 +finally, here I'm going to print out the value + +127 +00:06:44,570 --> 00:06:50,130 +of count. Okay, now that I have this code up. So let's imagine that I + +128 +00:06:50,130 --> 00:06:55,665 +want to, again as I did before, extract this matter. So, I'm going to + +129 +00:06:55,665 --> 00:06:58,430 +give you a second. Have a look at this and see, if you see + +130 +00:06:58,430 --> 00:07:02,170 +any problem with that. Feel free to stop the video, if you need more time. + +131 +00:07:07,350 --> 00:07:11,440 +So the problem here is that I have two side effects. + +132 +00:07:11,440 --> 00:07:14,820 +Both outstanding and count are modified. And therefore it's not really + +133 +00:07:14,820 --> 00:07:19,600 +possible to extract this method, and preserve the semantics of this + +134 +00:07:19,600 --> 00:07:23,260 +code. Let's see if Eclipse will be able to figure that out. + +135 +00:07:26,130 --> 00:07:28,950 +And it does. If we try to extract the matter here, + +136 +00:07:28,950 --> 00:07:32,250 +you'll tell us that's an ambiguous return value. The selected block + +137 +00:07:32,250 --> 00:07:35,800 +contains more than one assignment to look at variables. And the + +138 +00:07:35,800 --> 00:07:40,170 +affected variables are outstanding, just a Double and Count which is + +139 +00:07:40,170 --> 00:07:44,780 +an integer. So it will refuse to extract the method. So + +140 +00:07:44,780 --> 00:07:46,470 +at this point if we wanted to do that we have + +141 +00:07:46,470 --> 00:07:48,650 +we'll have to do the re-factoring a different way, but I + +142 +00:07:48,650 --> 00:07:51,110 +don't really want to get there. I want to conclude here, + +143 +00:07:51,110 --> 00:07:53,440 +and I hope this this little demo helped you + +144 +00:07:53,440 --> 00:07:55,310 +realize how useful it can be to use an + +145 +00:07:55,310 --> 00:07:58,270 +id that supports re-factoring that can automate this important + +146 +00:07:58,270 --> 00:08:00,160 +task. And I also encourage you to try to play + +147 +00:08:00,160 --> 00:08:03,170 +with this, and try to use different re-factoring's, on + +148 +00:08:03,170 --> 00:08:05,480 +your code. So as to get familiar with the kind + +149 +00:08:05,480 --> 00:08:08,060 +of re-factoring's that are supported by the ID. And + +150 +00:08:08,060 --> 00:08:10,800 +also with the re-factoring's themselves and how should be used. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..07f5e44 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt @@ -0,0 +1,31 @@ +1 +00:00:00,160 --> 00:00:02,580 +After the demo I would like to have a little quiz + +2 +00:00:02,580 --> 00:00:05,430 +about the extract method refactoring. And I would like to ask you + +3 +00:00:05,430 --> 00:00:08,910 +when is it appropriate to apply the extract method refactoring. Here I + +4 +00:00:08,910 --> 00:00:11,890 +have a set of possible scenarios. First one is when there is + +5 +00:00:11,890 --> 00:00:14,730 +duplicated code in two or more methods. When a class is too + +6 +00:00:14,730 --> 00:00:17,730 +large. When the names of two classes are too similar. Or when + +7 +00:00:17,730 --> 00:00:20,840 +a method is highly coupled with a class other than the one + +8 +00:00:20,840 --> 00:00:24,370 +where it is defined. So as usual, please mark all that apply. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..6545de0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,83 @@ +1 +00:00:00,110 --> 00:00:03,000 +The first scenario is the typical case in which it is + +2 +00:00:03,000 --> 00:00:07,040 +recommended to use the extract method refactoring, when there is duplicated code + +3 +00:00:07,040 --> 00:00:09,190 +in two or more methods and we want to take this + +4 +00:00:09,190 --> 00:00:12,420 +code and factor is out, and basically have the two methods called + +5 +00:00:12,420 --> 00:00:14,960 +a third method, which is the one we create using the + +6 +00:00:14,960 --> 00:00:18,060 +refactoring. When a class is too large, normally we don't want to + +7 +00:00:18,060 --> 00:00:21,330 +apply the extract. Extract method. Instead, in this cases, it is + +8 +00:00:21,330 --> 00:00:22,900 +usually more appropriate to use the + +9 +00:00:22,900 --> 00:00:26,420 +extract class or extract subclass refactorings. + +10 +00:00:26,420 --> 00:00:29,750 +Analogously, when the names of two classes are too similar, extracting a + +11 +00:00:29,750 --> 00:00:32,729 +method will normally not help much. And all we need to do + +12 +00:00:32,729 --> 00:00:35,810 +in case having too similar names is actually a problem. Is to + +13 +00:00:35,810 --> 00:00:39,600 +rename one of the two classes, or both, if we wish. Finally, + +14 +00:00:39,600 --> 00:00:42,530 +it is definitely appropriate to apply the extract method of refactoring in + +15 +00:00:42,530 --> 00:00:45,900 +cases in which a method is highly coupled with a class other + +16 +00:00:45,900 --> 00:00:48,330 +than the one where it is defined. In this case, which we + +17 +00:00:48,330 --> 00:00:51,740 +will discuss also later in the lesson, the extract method of refactoring + +18 +00:00:51,740 --> 00:00:55,710 +allows us to extract part of the metal to With the other class. + +19 +00:00:55,710 --> 00:00:58,690 +Then we can take the matter that we just extracted and move it + +20 +00:00:58,690 --> 00:01:01,880 +to the class where it actually belongs. So the extract method is one + +21 +00:01:01,880 --> 00:01:05,560 +of the two refactorings that it is appropriate to apply in these cases. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt new file mode 100644 index 0000000..0aae00c --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt @@ -0,0 +1,143 @@ +1 +00:00:00,150 --> 00:00:02,520 +Now that we saw a number of refactorings, we also saw + +2 +00:00:02,520 --> 00:00:05,950 +how refactorings can be performed automatically within an ID, I'd like + +3 +00:00:05,950 --> 00:00:09,230 +to make you aware of some risks involved with the user + +4 +00:00:09,230 --> 00:00:12,510 +refactorings. Refactorings are a very powerful tool, but you also have to + +5 +00:00:12,510 --> 00:00:15,820 +be careful, first of all when you do more complex refactorings, + +6 +00:00:15,820 --> 00:00:18,540 +you may also introduce subtle faults. What, we don't really call + +7 +00:00:18,540 --> 00:00:21,040 +regression errors. You might change something in the class. You might + +8 +00:00:21,040 --> 00:00:23,140 +think that that's a behavior preserving + +9 +00:00:23,140 --> 00:00:25,200 +transformation when considering the whole code, + +10 +00:00:25,200 --> 00:00:27,860 +and instead your change is affecting the behavior of some of the + +11 +00:00:27,860 --> 00:00:30,980 +other parts of the code. So, it's introducing a regression that will cause + +12 +00:00:30,980 --> 00:00:32,670 +some other functionality, some other piece + +13 +00:00:32,670 --> 00:00:34,320 +of functionality some other feature, to + +14 +00:00:34,320 --> 00:00:37,190 +work incorrectly. So you always have to be careful, and as we saw + +15 +00:00:37,190 --> 00:00:39,750 +at the beginning one way to avoid that is to run tests. + +16 +00:00:39,750 --> 00:00:43,080 +Every time you make a refactoring every time you change your code and + +17 +00:00:43,080 --> 00:00:46,280 +refactor your code. So is to get the least some confidence in + +18 +00:00:46,280 --> 00:00:47,540 +the fact that your refactoring is + +19 +00:00:47,540 --> 00:00:50,290 +indeed behavior preserving. Also consider the refactoring + +20 +00:00:50,290 --> 00:00:54,680 +should not. Be abused. Refactoring should be performed when it's needed. It's + +21 +00:00:54,680 --> 00:00:57,570 +useful to improve the design of your code when you see problems + +22 +00:00:57,570 --> 00:00:59,680 +with the design of the code. Shouldn't just be applied for the + +23 +00:00:59,680 --> 00:01:02,720 +final code because you can apply, for example, easily within a tool. + +24 +00:01:02,720 --> 00:01:06,030 +So be careful not over doing it when you refactor. And for + +25 +00:01:06,030 --> 00:01:08,310 +the same reason that we mentioned at the beginning, you should be + +26 +00:01:08,310 --> 00:01:10,600 +particularly careful when you're using refactoring + +27 +00:01:10,600 --> 00:01:12,290 +for systems that are in production. + +28 +00:01:12,290 --> 00:01:15,260 +Because if you introduce a problem, before the system goes in production, + +29 +00:01:15,260 --> 00:01:16,750 +then you might be able to catch it earlier, + +30 +00:01:16,750 --> 00:01:19,780 +with testing. Or before it's released. But, if you introduce + +31 +00:01:19,780 --> 00:01:21,750 +a problem for a system in production, then you have + +32 +00:01:21,750 --> 00:01:24,440 +to issue a new version of the code. You'll be + +33 +00:01:24,440 --> 00:01:26,860 +affecting, you might be affecting some users, because the code + +34 +00:01:26,860 --> 00:01:29,050 +fails on their machine. So, you have to be twice + +35 +00:01:29,050 --> 00:01:31,190 +as careful, when you are doing refactoring, when you're changing + +36 +00:01:31,190 --> 00:01:33,010 +your code for a system that is already in production. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt new file mode 100644 index 0000000..e09868d --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,080 --> 00:00:03,800 +Let's also talk about the cost of refactoring. Refactoring might be + +2 +00:00:03,800 --> 00:00:06,750 +free or almost free if you're using a tool to do refactoring + +3 +00:00:06,750 --> 00:00:08,570 +as we did in our demo. But that's not always the + +4 +00:00:08,570 --> 00:00:12,530 +case. In many cases, refactoring involves quite a bit of manual work + +5 +00:00:12,530 --> 00:00:16,309 +if you're doing some manual refactoring. And how much that costs + +6 +00:00:16,309 --> 00:00:19,460 +depends on how well the operations on the source code are supported. + +7 +00:00:19,460 --> 00:00:22,379 +You might have partial support from an ID. You might have complete + +8 +00:00:22,379 --> 00:00:25,017 +support, in which case it's greater. Or you might have no support, + +9 +00:00:25,017 --> 00:00:26,879 +in which case you have to be very careful about + +10 +00:00:26,879 --> 00:00:28,888 +how you change your code and how you check that you + +11 +00:00:28,888 --> 00:00:32,030 +didn't change the behavior of the code. There's also an additional + +12 +00:00:32,030 --> 00:00:34,460 +cost associated with refactoring. Remember + +13 +00:00:34,460 --> 00:00:36,990 +that refactoring relies heavily on testing + +14 +00:00:36,990 --> 00:00:39,808 +after each small step of refactoring. So you might have + +15 +00:00:39,808 --> 00:00:43,451 +to develop test cases, specifically to check your refactoring. And even + +16 +00:00:43,451 --> 00:00:47,163 +if you have an existing test because, for example, you're working + +17 +00:00:47,163 --> 00:00:50,235 +some agile context and therefore you develop a lot of UNIX + +18 +00:00:50,235 --> 00:00:53,550 +test cases before writing your code. And therefore you have a good + +19 +00:00:53,550 --> 00:00:56,635 +regression test with it you can use every time you modify your code. + +20 +00:00:56,635 --> 00:00:59,550 +Nevertheless, when you refactor and you change your code, you might need + +21 +00:00:59,550 --> 00:01:03,255 +to update your test so it's not only the development of the test + +22 +00:01:03,255 --> 00:01:05,379 +cases but also it's maintaining the test cases. And if you have + +23 +00:01:05,379 --> 00:01:07,970 +a lot of test cases, you have to maintain more test cases. So + +24 +00:01:07,970 --> 00:01:12,460 +that's a cost that is not directly visible but can affect quite + +25 +00:01:12,460 --> 00:01:15,800 +a bit the overall cost of refactoring and the overall cost of system + +26 +00:01:15,800 --> 00:01:18,342 +development therefore. And finally, you should not + +27 +00:01:18,342 --> 00:01:21,191 +under estimate the cost of documentation maintenance. + +28 +00:01:21,191 --> 00:01:24,241 +Applying refactoring may involve changes in interfaces, + +29 +00:01:24,241 --> 00:01:26,528 +names, for example, names of classes. And + +30 +00:01:26,528 --> 00:01:29,384 +when you make this kind of changes, you might need to update the documentation, + +31 +00:01:29,384 --> 00:01:30,890 +and that's also cost. It's something that + +32 +00:01:30,890 --> 00:01:32,900 +takes effort and therefore should be considered. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..a50a2e5 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,090 --> 00:00:02,790 +Let me start this lesson by discussing what is refactoring. + +2 +00:00:02,790 --> 00:00:06,590 +Refactoring is the process of applying transformation or refactoring to a + +3 +00:00:06,590 --> 00:00:09,320 +program. So as to obtain a refactor program. With an + +4 +00:00:09,320 --> 00:00:12,850 +improved design but with same functionality as the original program. So + +5 +00:00:12,850 --> 00:00:15,520 +key aspect of refactoring is the fact that refactoring should + +6 +00:00:15,520 --> 00:00:18,150 +be somatic to perserving So what is the main goal of + +7 +00:00:18,150 --> 00:00:22,030 +refactoring? The goal is to keep the program readable, understandable, and + +8 +00:00:22,030 --> 00:00:25,260 +maintainable as we evolve it. And to do this by eliminating + +9 +00:00:25,260 --> 00:00:28,530 +small problems soon, so that you can avoid big trouble later. And + +10 +00:00:28,530 --> 00:00:31,750 +I want to stress once more a key feature of refactoring, which + +11 +00:00:31,750 --> 00:00:34,790 +is the fact that it is behavior per serving. But how can + +12 +00:00:34,790 --> 00:00:38,130 +we ensure that the refactoring is behavior per serving? In other words, + +13 +00:00:38,130 --> 00:00:40,980 +how can we ensure that the program does the same thing before + +14 +00:00:40,980 --> 00:00:43,560 +and after applying a refactoring. So what we would like to do + +15 +00:00:43,560 --> 00:00:47,160 +is to have some guarantee that, that happens. And unfortunately in general, + +16 +00:00:47,160 --> 00:00:50,360 +there are no guarantees. But something we can do is to test + +17 +00:00:50,360 --> 00:00:53,690 +the code. For example, we can write tests that exercise the + +18 +00:00:53,690 --> 00:00:56,390 +parts of the program affected by the refactoring, and if we're in + +19 +00:00:56,390 --> 00:00:59,430 +a [INAUDIBLE] context, we might already have plenty of test cases + +20 +00:00:59,430 --> 00:01:01,914 +that exercise that part of the code. So we might just have + +21 +00:01:01,914 --> 00:01:04,780 +to rerun the test cases after the refactoring. And in fact, + +22 +00:01:04,780 --> 00:01:07,930 +that's a very advantageous situation, and that's a very good use of + +23 +00:01:07,930 --> 00:01:10,970 +existing test cases. And I want to make sure that you remember, + +24 +00:01:10,970 --> 00:01:15,500 +and that you beware that tests provide no guarantees. Testing can only + +25 +00:01:15,500 --> 00:01:18,990 +show the presence of defects, but cannot demonstrate their absence. + +26 +00:01:18,990 --> 00:01:21,090 +So we can use testing to get confidence in our + +27 +00:01:21,090 --> 00:01:23,990 +refactorings, but we can't really guarantee that the refactorings are + +28 +00:01:23,990 --> 00:01:26,820 +behavior preserving. I'd also like to point out that for some + +29 +00:01:26,820 --> 00:01:30,100 +simple refactoring, we can use a static analysis to actually + +30 +00:01:30,100 --> 00:01:33,160 +provide these guarantees. And in fact we will see examples of + +31 +00:01:33,160 --> 00:01:37,050 +such refactorings that are incorporated into IDs and that leverage + +32 +00:01:37,050 --> 00:01:40,070 +these kinds of analysis to perform refactoring in a safe way. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt new file mode 100644 index 0000000..53938de --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,088 --> 00:00:02,860 +Now I want to conclude this discussion on refactoring by telling you + +2 +00:00:02,860 --> 00:00:07,190 +when you should not refactor. One first clear case is when + +3 +00:00:07,190 --> 00:00:10,410 +your code is broken. I want to make it very clear, refactoring + +4 +00:00:10,410 --> 00:00:13,450 +is not a way to fix your code in terms of its + +5 +00:00:13,450 --> 00:00:16,250 +functionality. It's a way to improve the design of your code. + +6 +00:00:16,250 --> 00:00:19,040 +So if your code does not compile or does not run + +7 +00:00:19,040 --> 00:00:21,780 +in a stable way, it's probably better to throw it away + +8 +00:00:21,780 --> 00:00:25,250 +and rewrite it rather then trying to refactor it. By definition refactoring + +9 +00:00:25,250 --> 00:00:26,780 +should maintain the functionality of the + +10 +00:00:26,780 --> 00:00:28,360 +system. It should be behavior preserving. + +11 +00:00:28,360 --> 00:00:31,100 +So if the code was broken before, it, it's probably going to be broken + +12 +00:00:31,100 --> 00:00:33,950 +afterwards as well. You may also want to avoid refactoring when a + +13 +00:00:33,950 --> 00:00:37,370 +deadline is close. Well, first of all, because refactoring might take a long + +14 +00:00:37,370 --> 00:00:41,360 +time and therefore might introduce risks of being late for the deadline. + +15 +00:00:41,360 --> 00:00:44,555 +And also, because of what we said before about introducing problems, you don't + +16 +00:00:44,555 --> 00:00:47,780 +want to introduce problems that might take you time to fix right before a + +17 +00:00:47,780 --> 00:00:50,660 +deadline. So if the deadline is too close, you might want to avoid + +18 +00:00:50,660 --> 00:00:54,310 +refactoring the code at that point. And finally, do not refactor if there + +19 +00:00:54,310 --> 00:00:58,430 +is no reason to. As we said before, you should refactor on demand. You + +20 +00:00:58,430 --> 00:01:00,960 +see a problem with the design of your code, with the structure of your + +21 +00:01:00,960 --> 00:01:03,790 +code, it's okay to refactor. If the code is fine, there is no reason + +22 +00:01:03,790 --> 00:01:06,470 +to refactor. I know that refactoring is fine, but you don't want to do + +23 +00:01:06,470 --> 00:01:09,280 +it all the time. The next thing I want to discuss, after discussing when + +24 +00:01:09,280 --> 00:01:12,970 +not to refactor, is when to refactor without an indication that will tell us + +25 +00:01:12,970 --> 00:01:15,820 +that it's time to refactor the code. And that leads us to the discussion + +26 +00:01:15,820 --> 00:01:17,280 +of a very interesting concept. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt new file mode 100644 index 0000000..240d37b --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,070 --> 00:00:03,450 +The concept of bad smells. What are bad smells? Well, we + +2 +00:00:03,450 --> 00:00:06,700 +mentioned earlier that refactoring is typically applied when there is something + +3 +00:00:06,700 --> 00:00:09,130 +that does not look right, does not feel right in the + +4 +00:00:09,130 --> 00:00:12,260 +code. And that's exactly what bad smells are. Bad smells, or + +5 +00:00:12,260 --> 00:00:15,320 +code smells if you wish, are symptoms in the code of + +6 +00:00:15,320 --> 00:00:18,868 +a program that might indicate deeper problems. So there might be + +7 +00:00:18,868 --> 00:00:21,775 +parts of my system, classes in my systems, that just don't + +8 +00:00:21,775 --> 00:00:25,309 +smell right, and it feels like there's, there might be something wrong + +9 +00:00:25,309 --> 00:00:29,010 +with them. And if you are an experienced developer just like Brad, + +10 +00:00:29,010 --> 00:00:31,320 +you'll be able to figure out there is something wrong with the + +11 +00:00:31,320 --> 00:00:33,950 +classes. You'll be able to smell that there's something wrong and you'll + +12 +00:00:33,950 --> 00:00:36,880 +do something about it. And I want to mention one more, just to make + +13 +00:00:36,880 --> 00:00:39,270 +sure that we're all on the same page here. That these bad + +14 +00:00:39,270 --> 00:00:43,070 +smells are usually not bugs and don't prevent the program from functioning. They + +15 +00:00:43,070 --> 00:00:46,190 +however indicate weaknesses in the design of the system that might cause + +16 +00:00:46,190 --> 00:00:48,480 +problems during maintenance. In other words, + +17 +00:00:48,480 --> 00:00:50,440 +they might make the code less maintainable, + +18 +00:00:50,440 --> 00:00:53,650 +harder to understand, and so on. Just like refactorings, + +19 +00:00:53,650 --> 00:00:56,610 +there's also many possible different bad smells. So what + +20 +00:00:56,610 --> 00:00:59,160 +I'm providing here is just a possible list of + +21 +00:00:59,160 --> 00:01:02,190 +some very common bad smells. And you can find plenty + +22 +00:01:02,190 --> 00:01:04,349 +of information on this online. So what I want + +23 +00:01:04,349 --> 00:01:06,910 +to do next is just to cover before finishing the + +24 +00:01:06,910 --> 00:01:08,700 +lesson a few of those to show you some + +25 +00:01:08,700 --> 00:01:11,140 +examples of smells and what you can do about them. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt new file mode 100644 index 0000000..b26a698 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt @@ -0,0 +1,263 @@ +1 +00:00:00,100 --> 00:00:03,080 +The first example I want to mention is this called duplicated + +2 +00:00:03,080 --> 00:00:06,950 +code. So what happens here what the symptom is, is that you + +3 +00:00:06,950 --> 00:00:10,400 +have the same piece of code. The same fragment of code or + +4 +00:00:10,400 --> 00:00:14,570 +code structure replicated in more than one place. And that's pretty common + +5 +00:00:14,570 --> 00:00:16,880 +when we do for example copy and paste programming. Is something + +6 +00:00:16,880 --> 00:00:19,730 +that we mention at the beginning of the lessons. So for example + +7 +00:00:19,730 --> 00:00:22,780 +we are just instead reimplementing a piece of functionality we know we + +8 +00:00:22,780 --> 00:00:25,510 +already have. We simply copy from a different part of the code. + +9 +00:00:25,510 --> 00:00:27,760 +So what do you do if you have duplicated code? This can + +10 +00:00:27,760 --> 00:00:30,100 +be a problem over time because we might end up with a lot + +11 +00:00:30,100 --> 00:00:34,480 +of duplication in your system. You can use the extract method. Refactoring that + +12 +00:00:34,480 --> 00:00:37,610 +we just saw, and basically create a method that has exactly the same + +13 +00:00:37,610 --> 00:00:40,700 +function as this fragment of code and then replace the fragment of code + +14 +00:00:40,700 --> 00:00:43,030 +with an invocation to run and you will do it in all the + +15 +00:00:43,030 --> 00:00:47,520 +places where the code is duplicated. That simply finds the code and favors + +16 +00:00:47,520 --> 00:00:48,660 +reuse, because there can be more + +17 +00:00:48,660 --> 00:00:51,050 +places that benefit from that additional method. + +18 +00:00:51,050 --> 00:00:54,960 +Especially if it implements some popular piece of functionality. Another example + +19 +00:00:54,960 --> 00:00:57,930 +of best mal a typical one is the long method. So you + +20 +00:00:57,930 --> 00:01:00,530 +have a very long method with a lot of statements. And we + +21 +00:01:00,530 --> 00:01:03,570 +know that the longer procedure, the more difficult it is to understand + +22 +00:01:03,570 --> 00:01:05,650 +it and maintain it. So what I'm going to do in this + +23 +00:01:05,650 --> 00:01:08,690 +case is to factor in such as an extract method or a + +24 +00:01:08,690 --> 00:01:12,900 +decompose conditional to make the code simpler, shorten it. And extract some + +25 +00:01:12,900 --> 00:01:16,450 +of the functionality into other methods. So basically break down the method + +26 +00:01:16,450 --> 00:01:20,180 +in smaller methods that are more cohesive. Another typical example + +27 +00:01:20,180 --> 00:01:22,380 +of best mail which is something that can happen very + +28 +00:01:22,380 --> 00:01:25,720 +commonly during maintenance, is that you keep adding functionality to + +29 +00:01:25,720 --> 00:01:28,470 +a class and you end up with a large class. So + +30 +00:01:28,470 --> 00:01:32,410 +class is clearly to big. It contains too many fields + +31 +00:01:32,410 --> 00:01:35,620 +too many methods, and is just too complex to understand. This + +32 +00:01:35,620 --> 00:01:37,990 +case the obvious solution is to use the extract class + +33 +00:01:37,990 --> 00:01:42,230 +or subclass and basically break down the class in multiple classes. + +34 +00:01:42,230 --> 00:01:45,390 +Each one with a more cohesive piece of functionality. So, the + +35 +00:01:45,390 --> 00:01:46,930 +classes are more cohesive, are more + +36 +00:01:46,930 --> 00:01:48,360 +understandable, and the overall structure The + +37 +00:01:48,360 --> 00:01:52,440 +structure of the system is improved. Shotgun surgery is an interesting smell + +38 +00:01:52,440 --> 00:01:55,980 +and the case here is we are in a situation and you, + +39 +00:01:55,980 --> 00:01:58,270 +probably will happen to you, it definitely happened to me, in + +40 +00:01:58,270 --> 00:02:01,110 +which every time you make some kind of change to the system + +41 +00:02:01,110 --> 00:02:03,850 +you have to make many little changes. All over the place to + +42 +00:02:03,850 --> 00:02:07,280 +many different classes. And this can be a symptom of the fact + +43 +00:02:07,280 --> 00:02:11,080 +that the functionality is spread among these different classes. So + +44 +00:02:11,080 --> 00:02:13,610 +there's too much coupling between the classes and too little + +45 +00:02:13,610 --> 00:02:16,540 +cohesion within the classes. Also in this case you can + +46 +00:02:16,540 --> 00:02:19,540 +use refactoring, for example by using the move method or move + +47 +00:02:19,540 --> 00:02:22,650 +field or inline class to bring the pieces of related + +48 +00:02:22,650 --> 00:02:26,470 +functionality together. So that your resulting classes are more cohesive, you + +49 +00:02:26,470 --> 00:02:29,220 +reduce the dependencies between the different classes, and you address + +50 +00:02:29,220 --> 00:02:32,305 +this problem. Because at this point, each class is much more + +51 +00:02:32,305 --> 00:02:34,020 +self-contained and therefore it can be + +52 +00:02:34,020 --> 00:02:36,100 +modified by itself without having to affect + +53 +00:02:36,100 --> 00:02:38,560 +the rest of the system. The last smell I want to mention is + +54 +00:02:38,560 --> 00:02:42,040 +one I really like, is the feature envy, and it refers to a + +55 +00:02:42,040 --> 00:02:45,340 +method that seems more interested In a class other than the one it + +56 +00:02:45,340 --> 00:02:48,370 +belongs to. So for example this method is using a lot of public + +57 +00:02:48,370 --> 00:02:51,030 +fields of another class, is calling a lot of methods of the other + +58 +00:02:51,030 --> 00:02:53,830 +class. And so in this case the solution is really clear. What you + +59 +00:02:53,830 --> 00:02:57,420 +want to do it to perform the extract method refactoring and then the move + +60 +00:02:57,420 --> 00:02:59,680 +method refactoring so as to take the jealous + +61 +00:02:59,680 --> 00:03:01,210 +method out of the class where it doesn't + +62 +00:03:01,210 --> 00:03:04,770 +belong and get it home. To the class where it really belongs and once more the + +63 +00:03:04,770 --> 00:03:06,790 +effect of this is that you decrease the + +64 +00:03:06,790 --> 00:03:09,990 +coupling between the two classes and therefore you + +65 +00:03:09,990 --> 00:03:11,910 +have a better system and also you eliminate + +66 +00:03:11,910 --> 00:03:13,150 +the envy. Which is always a good thing. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt new file mode 100644 index 0000000..971d639 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt @@ -0,0 +1,31 @@ +1 +00:00:00,100 --> 00:00:01,620 +So now, I would like for you to tell me + +2 +00:00:01,620 --> 00:00:04,810 +which of the following can be considered bad smells in + +3 +00:00:04,810 --> 00:00:07,320 +the context of refactoring. The fact that the program takes + +4 +00:00:07,320 --> 00:00:10,070 +too long to execute? The fact that method M in class + +5 +00:00:10,070 --> 00:00:12,460 +C is very long? Or the, the fact that Class + +6 +00:00:12,460 --> 00:00:16,120 +Cat and Dog are subclasses of class Animal? Or finally the + +7 +00:00:16,120 --> 00:00:18,960 +fact that every time we modify method M1 we also + +8 +00:00:18,960 --> 00:00:22,120 +need to modify method M2? So please mark all that apply. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt new file mode 100644 index 0000000..2773116 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt @@ -0,0 +1,75 @@ +1 +00:00:00,110 --> 00:00:03,090 +So let's look at this one by one. The fact the program takes + +2 +00:00:03,090 --> 00:00:06,620 +too long to execute is not really a bad smell. It probably indicates + +3 +00:00:06,620 --> 00:00:08,800 +some problem with the code and the fact that we might need to + +4 +00:00:08,800 --> 00:00:11,420 +modify the code to make it more efficient, but it's not something that + +5 +00:00:11,420 --> 00:00:14,030 +we will normally classify it as a bad smell, so we're not going to + +6 +00:00:14,030 --> 00:00:17,850 +mark it. The second one, conversely, is definitely a bad smell. The fact + +7 +00:00:17,850 --> 00:00:21,700 +that the method is too long is a typical example of bad smell + +8 +00:00:21,700 --> 00:00:25,000 +and one in which we might want to apply some refactoring, for example, + +9 +00:00:25,000 --> 00:00:26,450 +the extract method or the + +10 +00:00:26,450 --> 00:00:29,240 +decomposed conditional refactorings. There's definitely + +11 +00:00:29,240 --> 00:00:32,159 +nothing wrong with the fact that the classes cat and dog + +12 +00:00:32,159 --> 00:00:35,600 +are subclasses of class animal. Actually, that sounds pretty appropriate, so + +13 +00:00:35,600 --> 00:00:38,270 +this is not a problem and definitely not a bad smell. + +14 +00:00:38,270 --> 00:00:40,990 +Whereas the fact that every time we modify method M1, + +15 +00:00:40,990 --> 00:00:44,210 +we also need to modify method some other method M2 as + +16 +00:00:44,210 --> 00:00:46,690 +a typical example of bad smell. So this can actually be + +17 +00:00:46,690 --> 00:00:50,590 +considered a specific example of what we just called "shotgun surgery." + +18 +00:00:50,590 --> 00:00:52,500 +So it is a case in which we might want to + +19 +00:00:52,500 --> 00:00:55,750 +use, for instance, the move method refactoring to fix the issue. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..7631180 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt @@ -0,0 +1,27 @@ +1 +00:00:00,120 --> 00:00:04,280 +So let's have a small quiz and see whether you can remember why can testing + +2 +00:00:04,280 --> 00:00:06,250 +guarantee that that a refactoring is behavior is + +3 +00:00:06,250 --> 00:00:08,590 +preserving. So why testing can only show the + +4 +00:00:08,590 --> 00:00:11,080 +absence of defects and not their presence? + +5 +00:00:11,080 --> 00:00:12,960 +Is that because testing and refactoring are different + +6 +00:00:12,960 --> 00:00:15,980 +activities? Because testing is inherently incomplete? Or, just + +7 +00:00:15,980 --> 00:00:19,560 +because testers are often inexperienced? Make your choice. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt new file mode 100644 index 0000000..7888f8d --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +1 +00:00:00,220 --> 00:00:03,180 +And the reason for this is because testing is inherently + +2 +00:00:03,180 --> 00:00:06,080 +incomplete. So let me re-size this a little bit, so that + +3 +00:00:06,080 --> 00:00:08,340 +I can make room for an illustration. And what I'm + +4 +00:00:08,340 --> 00:00:11,170 +going to show you here is just a reminder, that when we + +5 +00:00:11,170 --> 00:00:15,380 +test, we have a huge virtually infinite input domain, and + +6 +00:00:15,380 --> 00:00:17,956 +we have to derive from this input domain a few test + +7 +00:00:17,956 --> 00:00:21,330 +cases. By picking specific inputs in the domain, and of + +8 +00:00:21,330 --> 00:00:25,260 +course, corresponding outputs. And so what happens normally is that these + +9 +00:00:25,260 --> 00:00:28,280 +test cases represent the teeny tiny fraction of + +10 +00:00:28,280 --> 00:00:30,920 +the domain, and therefore testing is always incomplete. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt new file mode 100644 index 0000000..1da50e6 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt @@ -0,0 +1,131 @@ +1 +00:00:00,230 --> 00:00:02,000 +We saw at the beginning of the lesson, what are the + +2 +00:00:02,000 --> 00:00:05,490 +goals of refactoring? Or what are the reasons ,why we need to + +3 +00:00:05,490 --> 00:00:09,130 +refactor in the first place? The first reason is that requirements + +4 +00:00:09,130 --> 00:00:12,370 +change, and when the requirements change, we often need to change our + +5 +00:00:12,370 --> 00:00:16,356 +design accordingly. In other cases if any of the requirements unchange, + +6 +00:00:16,356 --> 00:00:19,690 +we might need to improve our design. And this happens for many + +7 +00:00:19,690 --> 00:00:22,300 +reasons. For example, we need to add a new feature, we + +8 +00:00:22,300 --> 00:00:25,330 +want to make the code more maintainable, and also in general programmers + +9 +00:00:25,330 --> 00:00:28,110 +don't come up with the best design the first time. So they might + +10 +00:00:28,110 --> 00:00:31,130 +need to adapt it after the fact. And the final reason I want to + +11 +00:00:31,130 --> 00:00:33,040 +mention is sloppiness, and to some + +12 +00:00:33,040 --> 00:00:35,700 +extent laziness, of programmers. And a typical + +13 +00:00:35,700 --> 00:00:38,520 +example of this is something that we all have done, which is copy + +14 +00:00:38,520 --> 00:00:41,890 +and paste programming. So instead of rewriting a new piece of code, because + +15 +00:00:41,890 --> 00:00:44,620 +we know that there is some code in some other parts for the + +16 +00:00:44,620 --> 00:00:47,900 +program that does a similar thing, we'll just copy the code over. And + +17 +00:00:47,900 --> 00:00:51,080 +before we know, we end up with tons of copies of the same functionality. + +18 +00:00:51,080 --> 00:00:54,150 +And when that happens, a good way of consolidating that code and + +19 +00:00:54,150 --> 00:00:57,580 +extracting that functionality is to use refactoring, for example, by creating a + +20 +00:00:57,580 --> 00:01:01,080 +method or a class that provides the functionality. And we'll see specific + +21 +00:01:01,080 --> 00:01:03,830 +examples of that. A question I would like to ask at this + +22 +00:01:03,830 --> 00:01:07,330 +point of the class is whether you have used refactoring before? So + +23 +00:01:07,330 --> 00:01:09,690 +I want you to take a second and think about it. And + +24 +00:01:09,690 --> 00:01:12,590 +no matter what you're history is, if you ever coded I bet + +25 +00:01:12,590 --> 00:01:16,180 +you any money that the answer is yes, you have done refactoring. + +26 +00:01:16,180 --> 00:01:17,300 +What do I mean? I'm going to give you an + +27 +00:01:17,300 --> 00:01:19,610 +example. I'm sure you renamed the class or a + +28 +00:01:19,610 --> 00:01:22,190 +method or change the name of some variables in + +29 +00:01:22,190 --> 00:01:25,490 +the code before. That's refactoring. Even something as simple as + +30 +00:01:25,490 --> 00:01:28,030 +renaming a class is refactoring, because, for example, it + +31 +00:01:28,030 --> 00:01:30,230 +might help you making your code more understandable. And of + +32 +00:01:30,230 --> 00:01:32,520 +course I'll admit that in this case, this is + +33 +00:01:32,520 --> 00:01:35,690 +a trivial refactoring, and there are much more interesting ones. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt new file mode 100644 index 0000000..3405b65 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt @@ -0,0 +1,171 @@ +1 +00:00:00,110 --> 00:00:02,340 +So if you follow my class so far, you know that + +2 +00:00:02,340 --> 00:00:04,570 +I like to give a little bit of history when I talk + +3 +00:00:04,570 --> 00:00:06,900 +about a specific topic. So I'm going to do the same also + +4 +00:00:06,900 --> 00:00:09,900 +in this case for refactoring. I'm going to start by mentioning, the fact + +5 +00:00:09,900 --> 00:00:13,440 +that refactoring is something that programmers have always done. I gave + +6 +00:00:13,440 --> 00:00:16,300 +you a trivial example just a minute ago of what refactoring is. + +7 +00:00:16,300 --> 00:00:18,080 +So even more complicated refactorings are + +8 +00:00:18,080 --> 00:00:20,880 +something that are commonplace for developers. + +9 +00:00:20,880 --> 00:00:23,110 +Somehow refactoring is especially important in + +10 +00:00:23,110 --> 00:00:25,240 +the context of object-oriented languages and + +11 +00:00:25,240 --> 00:00:28,080 +probably it's because the object-oriented features are well suited to + +12 +00:00:28,080 --> 00:00:31,640 +make designs flexible and reusable. Because of the fact that help + +13 +00:00:31,640 --> 00:00:35,120 +encapsulation, information hiding, and so they make it easier to + +14 +00:00:35,120 --> 00:00:38,330 +modify something without changing the functionality that it provides to the + +15 +00:00:38,330 --> 00:00:40,960 +outside world. However, you should keep in mind that refactoring + +16 +00:00:40,960 --> 00:00:44,330 +is really not specific to object oriented languages, you can also + +17 +00:00:44,330 --> 00:00:47,320 +refactor other languages, it's just more common to see it in + +18 +00:00:47,320 --> 00:00:50,450 +that context. So one of the first examples of a specific + +19 +00:00:50,450 --> 00:00:53,630 +discussion of what the refactorings are is Opdyke's PhD + +20 +00:00:53,630 --> 00:00:57,710 +thesis in 1990. Which discusses refactorings for small talk. + +21 +00:00:57,710 --> 00:00:59,360 +And some of you might be familiar with small + +22 +00:00:59,360 --> 00:01:02,600 +talk, which is a specific objectory language. And in + +23 +00:01:02,600 --> 00:01:06,590 +more recent times, refactoring's becoming increasing popular due to + +24 +00:01:06,590 --> 00:01:10,370 +lightweight development methodoogies, due to agile development, which is + +25 +00:01:10,370 --> 00:01:12,630 +something that we just discussed in this class. For + +26 +00:01:12,630 --> 00:01:15,830 +example, when we talked about extreme programming, we mentioned refactoring + +27 +00:01:15,830 --> 00:01:17,950 +a few times. And the reason why its so popular + +28 +00:01:17,950 --> 00:01:20,690 +is because re-factoring is one of the practices that help. + +29 +00:01:20,690 --> 00:01:24,780 +Making changes less expensive. And therefore adapt to changing requirements + +30 +00:01:24,780 --> 00:01:26,980 +and changing environments more quickly. + +31 +00:01:26,980 --> 00:01:29,140 +And continuing with historical perspective, one + +32 +00:01:29,140 --> 00:01:31,760 +of the milestones in the history of re-factoring [INAUDIBLE] is + +33 +00:01:31,760 --> 00:01:34,660 +a book by Martin Fowler. This is a book entitled + +34 +00:01:34,660 --> 00:01:37,610 +Improving the Design of Existing [INAUDIBLE]. And it contains a + +35 +00:01:37,610 --> 00:01:41,320 +catalog of refactorings, a list of bad smells, in code, and + +36 +00:01:41,320 --> 00:01:43,450 +we're going to see what that mean exactly. Nothing to + +37 +00:01:43,450 --> 00:01:45,570 +do with other kinds of bad smells. It talks about + +38 +00:01:45,570 --> 00:01:48,900 +guidelines on when to apply refactoring. And finally, which is + +39 +00:01:48,900 --> 00:01:52,540 +very useful, it provides example of code, before and after. + +40 +00:01:52,540 --> 00:01:54,660 +Applying the refactoring and we're going to use more of the + +41 +00:01:54,660 --> 00:01:57,190 +same style when discussing refactoring in the rest of this + +42 +00:01:57,190 --> 00:02:01,090 +lesson. More specifically what we're discussing next, are some examples + +43 +00:02:01,090 --> 00:02:05,130 +of refactoring and also some examples of code bad smells. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt new file mode 100644 index 0000000..b646b14 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt @@ -0,0 +1,43 @@ +1 +00:00:00,170 --> 00:00:03,630 +There are many refactorings in Fowler's book, and what I'm + +2 +00:00:03,630 --> 00:00:06,480 +showing here is just a partial list. And we're not going to + +3 +00:00:06,480 --> 00:00:08,930 +have time to go through the complete list of refactorings, + +4 +00:00:08,930 --> 00:00:10,830 +so what I'm going to do instead, I'm just going to pick a + +5 +00:00:10,830 --> 00:00:13,870 +few of those, but I'm going to explain in more depth, + +6 +00:00:13,870 --> 00:00:16,600 +and for which I'm going to provide some examples. In particular, we're + +7 +00:00:16,600 --> 00:00:18,000 +going to talk about the collapse + +8 +00:00:18,000 --> 00:00:20,630 +hierarchy refactoring, the consolidate conditional + +9 +00:00:20,630 --> 00:00:23,600 +expressions, the decompose conditionals, extract + +10 +00:00:23,600 --> 00:00:25,418 +method, extract class, and inline class. + +11 +00:00:25,418 --> 00:00:29,420 +And we're going to see each of those individually in the rest of the lesson. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt new file mode 100644 index 0000000..8711182 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,110 --> 00:00:03,080 +The first refactoring we're going to see is the collapse hierarchy + +2 +00:00:03,080 --> 00:00:06,340 +refactoring. When a software system undergoes a number of changes, over + +3 +00:00:06,340 --> 00:00:09,730 +time the collapse hierarchy may become, let's say, sub-optimal. There are + +4 +00:00:09,730 --> 00:00:11,300 +several refactorings that address this + +5 +00:00:11,300 --> 00:00:13,200 +issue for example, refactorings that allow + +6 +00:00:13,200 --> 00:00:15,900 +you to move methods and fields up and down the class + +7 +00:00:15,900 --> 00:00:18,360 +hierarchy. So what happens when you apply a number of these + +8 +00:00:18,360 --> 00:00:22,360 +refactorings, is that a subclass might become too similar to its + +9 +00:00:22,360 --> 00:00:25,878 +superclass and might not be adding much value to the system. + +10 +00:00:25,878 --> 00:00:28,010 +In this case, it is a good idea to merge + +11 +00:00:28,010 --> 00:00:31,300 +the classes together. That's exactly what the Collapse Hierarchy refactoring + +12 +00:00:31,300 --> 00:00:34,600 +does. Imagine, for instance, that we have two classes: employee + +13 +00:00:34,600 --> 00:00:38,210 +and salesman. And that salesman is just so similar to + +14 +00:00:38,210 --> 00:00:40,380 +employee that it does not make sense to keep them + +15 +00:00:40,380 --> 00:00:43,870 +separated. In this case, you could merge the two classes, + +16 +00:00:43,870 --> 00:00:46,730 +so that at the end of the refactoring, only employee + +17 +00:00:46,730 --> 00:00:50,070 +is left. And the resulting structure of the system is improved. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt new file mode 100644 index 0000000..be2b3fe --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt @@ -0,0 +1,131 @@ +1 +00:00:00,070 --> 00:00:00,860 +We're now going to talk about + +2 +00:00:00,860 --> 00:00:03,390 +the consolidate conditional expression refactoring. + +3 +00:00:03,390 --> 00:00:05,730 +A common situation in code is that you have a set + +4 +00:00:05,730 --> 00:00:08,530 +of conditionals with the same result. What that means that + +5 +00:00:08,530 --> 00:00:12,090 +sometimes the code contains a series of conditional checks in which + +6 +00:00:12,090 --> 00:00:14,760 +each check is different, yet the resulting action is the + +7 +00:00:14,760 --> 00:00:18,440 +same. In these cases, the code could be improved by combining + +8 +00:00:18,440 --> 00:00:22,100 +the conditionals using, for example, and, and or, as connectors. So + +9 +00:00:22,100 --> 00:00:25,390 +as to have a single conditional check, with a single result. + +10 +00:00:25,390 --> 00:00:28,500 +At that point you can also extract those conditional into a + +11 +00:00:28,500 --> 00:00:32,310 +method. And replace the conditional with a call, to debt matter consolidating + +12 +00:00:32,310 --> 00:00:35,110 +the conditional code in this way can make the checks clearer + +13 +00:00:35,110 --> 00:00:38,170 +by showing that you're really making a single check rather than multiple + +14 +00:00:38,170 --> 00:00:41,150 +checks, and extracted that condition and having that matter instead of + +15 +00:00:41,150 --> 00:00:44,550 +a condition can clarify your code by explaining why you're doing a + +16 +00:00:44,550 --> 00:00:47,350 +given check, rather than how you're doing it. You can see an + +17 +00:00:47,350 --> 00:00:52,020 +example of that situation in this code, which is the disabilityAmount method. + +18 +00:00:52,020 --> 00:00:54,580 +As the name of the method says, the purpose of this code + +19 +00:00:54,580 --> 00:00:58,300 +is to compute the disability amount for a given, for example, employee. + +20 +00:00:58,300 --> 00:01:01,250 +And there is a set of initial checks in the methods whose + +21 +00:01:01,250 --> 00:01:05,090 +goal is to decide whether there's this disabilityAmount should be instead zero. + +22 +00:01:05,090 --> 00:01:07,750 +And as you can see, there's multiple conditions. For example, there's a + +23 +00:01:07,750 --> 00:01:10,630 +check about the seniority level, and about the number of months that + +24 +00:01:10,630 --> 00:01:14,350 +the employee's been disabled. So far, whether the employee is part time + +25 +00:01:14,350 --> 00:01:17,060 +and the outcome of all these check is always the same. If they're + +26 +00:01:17,060 --> 00:01:19,740 +true, if the check is satisfied then there is no disability + +27 +00:01:19,740 --> 00:01:22,564 +amount. So the disabilityAmount is zero. So what I will do + +28 +00:01:22,564 --> 00:01:25,986 +if I apply the consolidate conditional expression to this matter, is + +29 +00:01:25,986 --> 00:01:29,690 +that I will take these three conditionals. I will put them together + +30 +00:01:29,690 --> 00:01:32,772 +by saying basically that if seniority is less than 2 or + +31 +00:01:32,772 --> 00:01:36,524 +monthsDisabled is greater than 12 or isPartTime is true then the + +32 +00:01:36,524 --> 00:01:40,170 +return should be zero. And once I have this combined conditional, + +33 +00:01:40,170 --> 00:01:42,601 +as I see here, I will just extract that into a method. |