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.