Refactor

Now, that we have all of our tests passing. 0:01 We can go back and see if there's anything we can improve about our code. 0:03 Changing code without changing its apparent functionality is called 0:07 refactoring. 0:11 Here are a few reasons we would want to refactor code. 0:12 It can make the code easier for others to read and comprehend. 0:15 It can make the code easier to maintain. 0:19 It could make it more efficient or faster. 0:22 It could make it easier to add additional code in later. 0:25 Sometimes refactoring is done just to make the code compliant with best practices and 0:28 conventions the others expect. 0:33 When coding there's a tendency to try to make every line of code 0:35 beautiful and elegant. 0:39 Beautiful and elegant code is great, and is often a good goal, but 0:40 we're trying to solve a problem first. 0:44 This often means writing and 0:46 rewriting code until we finally settle on something that just works. 0:48 With test-driven development we don't wanna spend too much time making our code 0:52 pretty, if we don't even know if it'll pass the test yet. 0:56 In other words we don't wanna spend a lot of time sculpting or 1:00 polishing our code, only to find out that it doesn't pass the tests. 1:03 A quick note on elegant code. 1:08 We also want to remember that other people will probably work 1:10 on our code in the future. 1:13 So we want to balance elegance and conciseness with clarity and readability. 1:15 I remember writing an elegant function once upon a time. 1:20 That a senior programmer kindly pointed out would be difficult to maintain for 1:23 newcomers who are not familiar with some of the syntax I used. 1:27 We also don't want to worry too much about performance at this point. 1:32 The main purpose of unit test is to test the functionality of a unit. 1:35 Not necessarily how efficiently it runs. 1:39 Performance can be affected by a lot of things that a unit test 1:42 can't capture and control. 1:46 Exerting unnecessary effort on this level of detail is known as 1:48 premature optimization. 1:52 We should try to figure code working first and 1:54 then decide if it's worth it to make further optimizations. 1:57 Knowing how much is good enough, 2:01 is a skill that can only be learned through experience. 2:02 Now that our tests are written, and we have a working implementation, 2:06 we can refactor and optimize to our heart's content. 2:09 And we have our unit test to back us up that all the way. 2:13 Let's take a look at the path class again. 2:16 The first thing I see is Visual Studio 2:19 didn't name things the way I like them named. 2:21 For example this pathLocations field. 2:24 I prefer it named _path. 2:26 So I'll rename this using a refactor. 2:29 To use the rename refactor in Visual Studio just hold down Ctrl and 2:32 Type R R twice. 2:36 Now I can just type in the name I want. 2:38 So we'll say _path. 2:40 Notice how it updates everywhere without variable's being used. 2:42 I'll get rid of this. 2:45 Also silly me, I should have written the IsOnPath method much more 2:49 by using the contains method provided by link. 2:54 I'll put this all in one line. 2:56 So I just change this to be _path.Contains, 2:59 and contains the link method. 3:06 You need to add the using. 3:10 And we'll pass in map location. 3:13 Visual Studio provides many other refactoring tools that 3:18 are worth checking out. 3:21 The great thing about doing refactoring in Visual Studio, 3:23 is that it can make changes in all the projects of a solution at the same time. 3:26 For example, changing the name of the IsOnPath method using the rename 3:31 refactoring also changes it everywhere else in the solution. 3:35 This is really helpful when we need to update all the tests that are calling 3:39 the IsOnPath method. 3:43 With that done let's run the test again to make sure that nothing broke. 3:44 Excellent, everything still passes. 3:52 With that we've successfully used test driven development to code the path class. 3:54 We can go tell our boss that this class is complete, not just coded, but complete. 4:00