00:0.24 Before we get into the actual details of changing and refactory in our code with
00:4.51 PyCharm. I want to make sure that we all have a precise definition of
00:8.54 what refactoring is. I feel like every now and then I hear re factoring
00:12.66 used as just a general term for improving the software and making it better.
00:17.87 Maybe adding features may be taken away things.
00:21.24 That's not exactly what refactoring is.
00:23.44 Refactoring is the process of restructuring existing computer code,
00:27.69 changing it but without changing its external behavior.
00:31.55 So no new features, no taking away features,
00:35.17 none of that kind of stuff.
00:36.6 It's just about what is the structure on the inside.
00:39.66 How can I change that around?
00:41.18 So it's more maintainable, more accessible,
00:43.19 more understandable without actually making it do anything effectively different.
00:48.44 The definition goes a little bit further to say.
00:50.59 Typically refactoring applies a series of standardized basic micro refactoring which is like rename
00:56.69 method, extract method. Move something between a class hierarchy from the base class to
01:2.7 a drive class, something like that,
01:4.34 each of which is usually a tiny change in the source code that either preserves the
01:8.06 behavior of the software or at least does not modify its conformance to functional requirements.
01:14.24 Now these refactories are powerful and useful but what you're going to see is often
01:18.35 there actually is a refactoring and then its opposite like an anti refactoring and
01:23.68 which one you use, depends on the situation so it's easy to kind of bounce
01:28.06 back and forth. Make this change,
01:30.35 make it go back the other way and just sort of fiddle with a code a
01:33.7 lot. It would be nice to have a really good understanding of when should I
01:38.24 apply, which change. So let me introduce you to one of my favorite theoretical
01:42.95 concepts of computer programming that is 'code smells'.
01:47.24 So often we come across code that is not broken,
01:50.47 it works. But when you look at it you're just like your nose kind of
01:54.72 curls up, you're like, yeah,
01:55.8 this is like rotting, this is not good.
01:58.09 Right, this is there something wrong with this code?
02:0.59 If you have that feeling often,
02:2.66 that's a natural reaction that you've developed as you've gotten better programming to what we would
02:7.73 call a code smell. So there's a whole bunch of these different ideas,
02:11.97 a particular smells and what's really cool about them is they often give you some sort
02:16.57 of guidance on what type of refactoring to apply.
02:19.76 So you come across some code,
02:21.22 you know like, oh, this is yuck and then you figure out in which
02:24.06 flavor, which variant of yucky is it?
02:25.76 And then that will give you some guidance on the re factories to apply.
02:28.74 Some of the common ones are duplicate code.
02:31.11 So if you see the same block of code in multiple locations,
02:34.93 let's say three or more. There's a good chance that should be a function that
02:38.77 is them being called in those different locations because this code duplication is super.
02:43.06 In system for missing some cases you make changes to it.
02:46.08 If you have a large classes got way too much going on.
02:48.95 Maybe it shouldn't be a large class.
02:51.02 Maybe it should be a smaller class that's built out of other smaller classes with composition
02:55.66 Real quick example might be a car.
02:59.28 A car could have a class describes the car part of that could describe the engine
03:3.86 part of that, could describe the wheels,
03:5.33 part of it could describe the interior and the electronics or a better version and not
03:10.49 so large class could be an engine class,
03:13.2 interior class, a wheel class and so on.
03:15.98 And then a car just has those things as fields,
03:19.01 right? Those that would be composition.
03:20.93 That's one of the types of refactories.
03:22.86 You could make the opposite of that would be a lazy or freeloader class that does
03:26.79 too little. So maybe you just get rid of it.
03:29.01 Maybe you don't need it. Maybe put those few things that it does elsewhere.
03:32.54 You've got to function in too many parameters.
03:34.94 Well, how do you fix that?
03:36.54 You might reorganize those into more intelligent pieces of information.
03:40.75 So a name tuple a class that's being passed instead of a bunch of primitive values
03:45.21 You can check out Wikipedia for a bunch more.
03:47.82 One of the one more quick idea out here.
03:49.82 That's related to code smells that I think will guide you in this whole refactoring
03:54.5 as well. And when you have these code smells is a really common thing to
03:59.2 do is to put a code comment around it to say yeah,
04:2.74 this is gross or there's something not so amazing here comment comment.
04:6.95 Here's why here's why here's why here's why When you think of code comments,
04:11.67 often people say you should have code comments because it describes what's going on.
04:15.51 But a lot of times you should find the urge to write a comment explaining what's
04:20.02 happening in the code. You should just take a minute and go,
04:22.62 Is this really trying to cover up some kind of code smell?
04:26.49 They're trying to hide it behind an explanation.
04:28.84 And so along those lines, I love to think of code comments as deodorant for
04:33.86 code smells. It's not always true.
04:36.38 Sometimes it's documentation and whatnot. But if you find you're putting comments over yucky code
04:42.45 to kind of cover up that badness.
04:44.8 Maybe some of these refactoring ideas that we're going to learn in this chapter should
04:47.78 be applied. So it doesn't actually need an explanation.
04:50.69 It's clear and clean and obvious.
04:52.5 All right, let's get into it.
