1 00:00:01,210 --> 00:00:03,650 Now, that we have all of our tests passing. 2 00:00:03,650 --> 00:00:07,670 We can go back and see if there's anything we can improve about our code. 3 00:00:07,670 --> 00:00:11,110 Changing code without changing its apparent functionality is called 4 00:00:11,110 --> 00:00:12,470 refactoring. 5 00:00:12,470 --> 00:00:15,940 Here are a few reasons we would want to refactor code. 6 00:00:15,940 --> 00:00:19,880 It can make the code easier for others to read and comprehend. 7 00:00:19,880 --> 00:00:21,570 It can make the code easier to maintain. 8 00:00:22,640 --> 00:00:25,630 It could make it more efficient or faster. 9 00:00:25,630 --> 00:00:28,670 It could make it easier to add additional code in later. 10 00:00:28,670 --> 00:00:33,350 Sometimes refactoring is done just to make the code compliant with best practices and 11 00:00:33,350 --> 00:00:34,970 conventions the others expect. 12 00:00:35,990 --> 00:00:39,290 When coding there's a tendency to try to make every line of code 13 00:00:39,290 --> 00:00:40,980 beautiful and elegant. 14 00:00:40,980 --> 00:00:44,550 Beautiful and elegant code is great, and is often a good goal, but 15 00:00:44,550 --> 00:00:46,890 we're trying to solve a problem first. 16 00:00:46,890 --> 00:00:48,630 This often means writing and 17 00:00:48,630 --> 00:00:52,960 rewriting code until we finally settle on something that just works. 18 00:00:52,960 --> 00:00:56,890 With test-driven development we don't wanna spend too much time making our code 19 00:00:56,890 --> 00:01:00,570 pretty, if we don't even know if it'll pass the test yet. 20 00:01:00,570 --> 00:01:03,499 In other words we don't wanna spend a lot of time sculpting or 21 00:01:03,499 --> 00:01:06,960 polishing our code, only to find out that it doesn't pass the tests. 22 00:01:08,140 --> 00:01:10,300 A quick note on elegant code. 23 00:01:10,300 --> 00:01:13,780 We also want to remember that other people will probably work 24 00:01:13,780 --> 00:01:15,270 on our code in the future. 25 00:01:15,270 --> 00:01:20,640 So we want to balance elegance and conciseness with clarity and readability. 26 00:01:20,640 --> 00:01:23,180 I remember writing an elegant function once upon a time. 27 00:01:23,180 --> 00:01:27,530 That a senior programmer kindly pointed out would be difficult to maintain for 28 00:01:27,530 --> 00:01:30,540 newcomers who are not familiar with some of the syntax I used. 29 00:01:32,040 --> 00:01:35,880 We also don't want to worry too much about performance at this point. 30 00:01:35,880 --> 00:01:39,790 The main purpose of unit test is to test the functionality of a unit. 31 00:01:39,790 --> 00:01:42,560 Not necessarily how efficiently it runs. 32 00:01:42,560 --> 00:01:46,040 Performance can be affected by a lot of things that a unit test 33 00:01:46,040 --> 00:01:48,100 can't capture and control. 34 00:01:48,100 --> 00:01:52,440 Exerting unnecessary effort on this level of detail is known as 35 00:01:52,440 --> 00:01:54,570 premature optimization. 36 00:01:54,570 --> 00:01:57,230 We should try to figure code working first and 37 00:01:57,230 --> 00:02:01,020 then decide if it's worth it to make further optimizations. 38 00:02:01,020 --> 00:02:02,810 Knowing how much is good enough, 39 00:02:02,810 --> 00:02:05,140 is a skill that can only be learned through experience. 40 00:02:06,610 --> 00:02:09,900 Now that our tests are written, and we have a working implementation, 41 00:02:09,900 --> 00:02:13,090 we can refactor and optimize to our heart's content. 42 00:02:13,090 --> 00:02:16,410 And we have our unit test to back us up that all the way. 43 00:02:16,410 --> 00:02:19,230 Let's take a look at the path class again. 44 00:02:19,230 --> 00:02:21,900 The first thing I see is Visual Studio 45 00:02:21,900 --> 00:02:24,260 didn't name things the way I like them named. 46 00:02:24,260 --> 00:02:26,890 For example this pathLocations field. 47 00:02:26,890 --> 00:02:29,440 I prefer it named _path. 48 00:02:29,440 --> 00:02:32,340 So I'll rename this using a refactor. 49 00:02:32,340 --> 00:02:36,620 To use the rename refactor in Visual Studio just hold down Ctrl and 50 00:02:36,620 --> 00:02:38,530 Type R R twice. 51 00:02:38,530 --> 00:02:40,530 Now I can just type in the name I want. 52 00:02:40,530 --> 00:02:42,780 So we'll say _path. 53 00:02:42,780 --> 00:02:45,990 Notice how it updates everywhere without variable's being used. 54 00:02:45,990 --> 00:02:46,840 I'll get rid of this. 55 00:02:49,180 --> 00:02:54,430 Also silly me, I should have written the IsOnPath method much more 56 00:02:54,430 --> 00:02:56,970 by using the contains method provided by link. 57 00:02:56,970 --> 00:02:58,240 I'll put this all in one line. 58 00:02:59,470 --> 00:03:06,071 So I just change this to be _path.Contains, 59 00:03:06,071 --> 00:03:10,258 and contains the link method. 60 00:03:10,258 --> 00:03:11,410 You need to add the using. 61 00:03:13,928 --> 00:03:16,010 And we'll pass in map location. 62 00:03:18,256 --> 00:03:21,405 Visual Studio provides many other refactoring tools that 63 00:03:21,405 --> 00:03:23,360 are worth checking out. 64 00:03:23,360 --> 00:03:26,480 The great thing about doing refactoring in Visual Studio, 65 00:03:26,480 --> 00:03:31,320 is that it can make changes in all the projects of a solution at the same time. 66 00:03:31,320 --> 00:03:35,380 For example, changing the name of the IsOnPath method using the rename 67 00:03:35,380 --> 00:03:39,340 refactoring also changes it everywhere else in the solution. 68 00:03:39,340 --> 00:03:43,140 This is really helpful when we need to update all the tests that are calling 69 00:03:43,140 --> 00:03:44,640 the IsOnPath method. 70 00:03:44,640 --> 00:03:48,700 With that done let's run the test again to make sure that nothing broke. 71 00:03:52,200 --> 00:03:54,940 Excellent, everything still passes. 72 00:03:54,940 --> 00:04:00,390 With that we've successfully used test driven development to code the path class. 73 00:04:00,390 --> 00:04:05,860 We can go tell our boss that this class is complete, not just coded, but complete.