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

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


Talk Python's Mastodon Michael Kennedy's Mastodon