Effective PyCharm Transcripts
Chapter: Refactoring
Lecture: What is refactoring really?

Learn more about this course
Login or purchase this course to watch this video and the rest of the course contents.
0:00 Before we get into the actual details of changing and refactory in our code with
0:04 PyCharm. I want to make sure that we all have a precise definition of
0:08 what refactoring is. I feel like every now and then I hear re factoring
0:12 used as just a general term for improving the software and making it better.
0:17 Maybe adding features may be taken away things.
0:21 That's not exactly what refactoring is.
0:23 Refactoring is the process of restructuring existing computer code,
0:27 changing it but without changing its external behavior.
0:31 So no new features, no taking away features,
0:35 none of that kind of stuff.
0:36 It's just about what is the structure on the inside.
0:39 How can I change that around?
0:41 So it's more maintainable, more accessible,
0:43 more understandable without actually making it do anything effectively different.
0:48 The definition goes a little bit further to say.
0:50 Typically refactoring applies a series of standardized basic micro refactoring which is like rename
0:56 method, extract method. Move something between a class hierarchy from the base class to
1:02 a drive class, something like that,
1:04 each of which is usually a tiny change in the source code that either preserves the
1:08 behavior of the software or at least does not modify its conformance to functional requirements.
1:14 Now these refactories are powerful and useful but what you're going to see is often
1:18 there actually is a refactoring and then its opposite like an anti refactoring and
1:23 which one you use, depends on the situation so it's easy to kind of bounce
1:28 back and forth. Make this change,
1:30 make it go back the other way and just sort of fiddle with a code a
1:33 lot. It would be nice to have a really good understanding of when should I
1:38 apply, which change. So let me introduce you to one of my favorite theoretical
1:42 concepts of computer programming that is 'code smells'.
1:47 So often we come across code that is not broken,
1:50 it works. But when you look at it you're just like your nose kind of
1:54 curls up, you're like, yeah,
1:55 this is like rotting, this is not good.
1:58 Right, this is there something wrong with this code?
2:00 If you have that feeling often,
2:02 that's a natural reaction that you've developed as you've gotten better programming to what we would
2:07 call a code smell. So there's a whole bunch of these different ideas,
2:11 a particular smells and what's really cool about them is they often give you some sort
2:16 of guidance on what type of refactoring to apply.
2:19 So you come across some code,
2:21 you know like, oh, this is yuck and then you figure out in which
2:24 flavor, which variant of yucky is it?
2:25 And then that will give you some guidance on the re factories to apply.
2:28 Some of the common ones are duplicate code.
2:31 So if you see the same block of code in multiple locations,
2:34 let's say three or more. There's a good chance that should be a function that
2:38 is them being called in those different locations because this code duplication is super.
2:43 In system for missing some cases you make changes to it.
2:46 If you have a large classes got way too much going on.
2:48 Maybe it shouldn't be a large class.
2:51 Maybe it should be a smaller class that's built out of other smaller classes with composition
2:55 Real quick example might be a car.
2:59 A car could have a class describes the car part of that could describe the engine
3:03 part of that, could describe the wheels,
3:05 part of it could describe the interior and the electronics or a better version and not
3:10 so large class could be an engine class,
3:13 interior class, a wheel class and so on.
3:15 And then a car just has those things as fields,
3:19 right? Those that would be composition.
3:20 That's one of the types of refactories.
3:22 You could make the opposite of that would be a lazy or freeloader class that does
3:26 too little. So maybe you just get rid of it.
3:29 Maybe you don't need it. Maybe put those few things that it does elsewhere.
3:32 You've got to function in too many parameters.
3:34 Well, how do you fix that?
3:36 You might reorganize those into more intelligent pieces of information.
3:40 So a name tuple a class that's being passed instead of a bunch of primitive values
3:45 You can check out Wikipedia for a bunch more.
3:47 One of the one more quick idea out here.
3:49 That's related to code smells that I think will guide you in this whole refactoring
3:54 as well. And when you have these code smells is a really common thing to
3:59 do is to put a code comment around it to say yeah,
4:02 this is gross or there's something not so amazing here comment comment.
4:06 Here's why here's why here's why here's why When you think of code comments,
4:11 often people say you should have code comments because it describes what's going on.
4:15 But a lot of times you should find the urge to write a comment explaining what's
4:20 happening in the code. You should just take a minute and go,
4:22 Is this really trying to cover up some kind of code smell?
4:26 They're trying to hide it behind an explanation.
4:28 And so along those lines, I love to think of code comments as deodorant for
4:33 code smells. It's not always true.
4:36 Sometimes it's documentation and whatnot. But if you find you're putting comments over yucky code
4:42 to kind of cover up that badness.
4:44 Maybe some of these refactoring ideas that we're going to learn in this chapter should
4:47 be applied. So it doesn't actually need an explanation.
4:50 It's clear and clean and obvious.
4:52 All right, let's get into it.