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
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.