1
00:00:00,040 --> 00:00:03,360
Welcome to the Deep Dive. 
Today we're plunging into a 

2
00:00:03,360 --> 00:00:06,600
really fascinating corner of 
software engineering code 

3
00:00:06,600 --> 00:00:09,480
smells. 
Right, not quite bugs, but 

4
00:00:09,640 --> 00:00:10,840
signals. 
Exactly. 

5
00:00:10,960 --> 00:00:13,720
They're not errors that crash 
your program, but more like 

6
00:00:13,720 --> 00:00:16,480
subtle indicators. 
You know, like a faint off 

7
00:00:16,480 --> 00:00:19,440
Keynote suggesting there might 
be deeper issues in the codes 

8
00:00:19,440 --> 00:00:21,840
design. 
And these can make software much

9
00:00:21,840 --> 00:00:26,880
harder to maintain, understand, 
or well build upon later. 

10
00:00:26,880 --> 00:00:29,960
Precisely, We're drawing our 
insights today from some fun 

11
00:00:30,040 --> 00:00:32,159
fundamental principles 
highlighted in text, like 

12
00:00:32,640 --> 00:00:34,800
software engineering a modern 
approach. 

13
00:00:34,920 --> 00:00:37,960
Good source, very thorough. 
It is so. 

14
00:00:37,960 --> 00:00:42,000
Our mission here is to unpack 
some specific, insightful code 

15
00:00:42,000 --> 00:00:44,920
smells, the kind that really 
affect how easily software can 

16
00:00:44,920 --> 00:00:47,560
be understood and modified. 
Things that can give you an edge

17
00:00:47,560 --> 00:00:49,680
in spotting robust code. 
OK, let's get into. 

18
00:00:49,760 --> 00:00:51,640
It Let's dive right in, starting
with something pretty 

19
00:00:51,640 --> 00:00:54,200
foundational about how objects, 
well, behave. 

20
00:00:54,760 --> 00:00:57,000
We're kicking things off with a 
concept that often comes up in 

21
00:00:57,000 --> 00:01:00,600
discussions about robust design.
Mutable objects flagged as a 

22
00:01:00,600 --> 00:01:03,000
code smell. 
Now, for those of us working 

23
00:01:03,000 --> 00:01:05,880
with complex systems, the 
difference between mutable and 

24
00:01:05,880 --> 00:01:09,520
immutable is basic, but it's 
worth revisiting why it matters 

25
00:01:09,520 --> 00:01:12,120
so much. 
So a mutable object lets you 

26
00:01:12,120 --> 00:01:16,040
change its internal state after 
it's created, like a piece of 

27
00:01:16,040 --> 00:01:18,280
clay you keep reshaping. 
Continually changing. 

28
00:01:18,520 --> 00:01:22,160
And a mutable object, though is 
fixed once it's made predictable

29
00:01:22,280 --> 00:01:24,520
steadfast. 
Set in stone, essentially. 

30
00:01:24,840 --> 00:01:27,680
But wait a minute, isn't 
flexibility usually a good thing

31
00:01:27,680 --> 00:01:31,160
in code? 
Why would being changeable be a 

32
00:01:31,200 --> 00:01:33,160
red flag? 
Why call it a smell? 

33
00:01:33,320 --> 00:01:35,600
That's exactly the core tension,
isn't it? 

34
00:01:35,960 --> 00:01:38,800
The real insight isn't just that
immutable objects are safe, 

35
00:01:38,800 --> 00:01:41,000
though they are. 
It's that they fundamentally 

36
00:01:41,000 --> 00:01:43,560
change how you debug. 
OK, how so? 

37
00:01:43,920 --> 00:01:46,920
Think of it like this. 
If you hand someone a printed 

38
00:01:46,920 --> 00:01:50,640
photograph, you know it won't 
spontaneously change color or 

39
00:01:50,640 --> 00:01:52,880
shape while they're holding it. 
Right, it's fixed. 

40
00:01:52,960 --> 00:01:56,120
That's immutability. 
You create an object, its state 

41
00:01:56,120 --> 00:01:58,560
is set and it will not change. 
Period. 

42
00:01:58,800 --> 00:02:02,320
So how do we actually achieve 
this set in stone quality in a 

43
00:02:02,320 --> 00:02:04,640
language like Java? 
Typically you declare all the 

44
00:02:04,640 --> 00:02:08,600
objects attributes its internal 
data as private and final. 

45
00:02:08,800 --> 00:02:11,520
Private, so nothing outside can 
mess with it directly. 

46
00:02:11,520 --> 00:02:15,400
Exactly. 
And final means once assigned, 

47
00:02:15,400 --> 00:02:19,400
maybe in the constructor, those 
attributes can't be reassigned, 

48
00:02:19,440 --> 00:02:22,960
their value is locked in. 
You also usually make the class 

49
00:02:22,960 --> 00:02:25,520
itself final. 
This stops other classes from 

50
00:02:25,520 --> 00:02:27,920
inheriting from it and 
potentially adding ways to 

51
00:02:27,920 --> 00:02:30,320
change the state, breaking the 
immutability promise. 

52
00:02:30,600 --> 00:02:33,680
Or you have to be very careful 
if you do allow subclassing. 

53
00:02:33,720 --> 00:02:35,640
So if you need a modified 
version. 

54
00:02:36,200 --> 00:02:37,920
Good point. 
You don't change the original, 

55
00:02:38,400 --> 00:02:40,880
ever. 
Instead, you create a brand new 

56
00:02:40,880 --> 00:02:44,600
instance of the object, but with
the desired changes incorporated

57
00:02:44,600 --> 00:02:47,200
into that new one. 
I see the original stays 

58
00:02:47,200 --> 00:02:49,600
untouched, yeah. 
Preserved precisely. 

59
00:02:49,600 --> 00:02:52,200
The original is still there 
exactly as it was. 

60
00:02:52,880 --> 00:02:55,320
A really classic example 
everyone knows is the String 

61
00:02:55,320 --> 00:02:57,960
object in Java. 
Let's say you have a String like

62
00:02:57,960 --> 00:03:01,280
deep dive OK, and you call a 
method like to uppercase on it. 

63
00:03:01,720 --> 00:03:04,440
That method doesn't actually 
change your original duck dive 

64
00:03:04,440 --> 00:03:05,520
string. 
It doesn't. 

65
00:03:05,520 --> 00:03:09,080
No, instead it gives you back a 
completely new String object, 

66
00:03:09,080 --> 00:03:11,720
which holds deep dive. 
Your original deep dive still 

67
00:03:11,720 --> 00:03:14,440
there, unchanged. 
That's immutability right there 

68
00:03:14,440 --> 00:03:17,800
in action. 
OK, that makes it very clear. 

69
00:03:18,760 --> 00:03:21,360
Now, the advantages that come 
from this guaranteed state, 

70
00:03:21,600 --> 00:03:23,840
They're pretty profound. 
First, they're safety and 

71
00:03:23,840 --> 00:03:26,760
sharing, right? 
Imagine passing a mutable object

72
00:03:26,760 --> 00:03:29,120
around a big application, maybe 
to different functions or 

73
00:03:29,120 --> 00:03:31,640
modules. 
Any one of those functions could

74
00:03:31,640 --> 00:03:33,600
potentially change that object's
state. 

75
00:03:33,800 --> 00:03:35,520
And you might not know who did 
it or when. 

76
00:03:35,600 --> 00:03:38,160
Exactly. 
Debugging that kind of 

77
00:03:38,160 --> 00:03:41,000
unexpected change can be an 
absolute nightmare. 

78
00:03:41,320 --> 00:03:44,920
Really elusive, time consuming 
bugs often stem from this. 

79
00:03:44,920 --> 00:03:48,240
You can imagine been there. 
But with immutable objects, you 

80
00:03:48,240 --> 00:03:51,600
pass them around with total 
confidence, you are guaranteed 

81
00:03:51,600 --> 00:03:53,520
their content won't magically 
change. 

82
00:03:53,800 --> 00:03:56,400
That's a huge leap in 
predictability for your system. 

83
00:03:57,240 --> 00:04:01,720
2nd, and this is critical today,
they are inherently thread safe.

84
00:04:01,920 --> 00:04:03,880
OK, this is important for 
concurrency. 

85
00:04:04,000 --> 00:04:06,800
Hugely important in systems 
where multiple threads are 

86
00:04:06,800 --> 00:04:09,880
running parts of your program at
the same time, you run into 

87
00:04:09,880 --> 00:04:11,680
problems like race conditions 
where. 

88
00:04:11,680 --> 00:04:15,080
The timing messes things U. 
Recisely because multiple 

89
00:04:15,080 --> 00:04:18,320
threads are trying to change the
same object state simultaneously

90
00:04:18,560 --> 00:04:21,560
and the final state depends on 
who gets there when it's 

91
00:04:21,560 --> 00:04:24,800
unpredictable. 
But if an object state can't 

92
00:04:24,800 --> 00:04:27,240
change if it's immutable. 
Then there's nothing for the 

93
00:04:27,240 --> 00:04:29,240
threads to race to change. 
Exactly. 

94
00:04:29,240 --> 00:04:32,080
Those kinds of concurrency 
problems just disappear by 

95
00:04:32,080 --> 00:04:33,880
design. 
This makes reasoning about 

96
00:04:33,880 --> 00:04:37,280
concurrent CON vastly simpler. 
You can share immutable objects 

97
00:04:37,280 --> 00:04:40,520
freely between threads without 
needing complex locks. 

98
00:04:40,640 --> 00:04:43,600
Wow, That distinction really 
highlights the benefit. 

99
00:04:43,600 --> 00:04:47,200
It's about stability and just 
eliminating a whole class of 

100
00:04:47,200 --> 00:04:49,280
really frustrating bugs by 
design. 

101
00:04:50,280 --> 00:04:53,320
And if you think about how often
we chase bugs that, yeah, we're 

102
00:04:53,320 --> 00:04:55,720
probably some object mutating 
unexpectedly. 

103
00:04:55,920 --> 00:04:58,400
So is the goal then to make 
everything immutable? 

104
00:04:58,640 --> 00:05:01,640
Is mutability just bad? 
That's a really good follow up 

105
00:05:01,640 --> 00:05:03,800
because context is absolutely 
key here. 

106
00:05:04,200 --> 00:05:07,160
It's not quite black and white. 
In certain programming 

107
00:05:07,160 --> 00:05:10,520
paradigms, like purely 
functional languages, objects 

108
00:05:10,520 --> 00:05:12,360
are actually immutable by 
definition. 

109
00:05:12,360 --> 00:05:14,240
It's the default way things 
work. 

110
00:05:14,240 --> 00:05:17,120
So in those languages the smell 
wouldn't really even be a 

111
00:05:17,120 --> 00:05:18,960
concept. 
Ah, interesting. 

112
00:05:19,080 --> 00:05:23,400
But in what we call imperative 
languages like Java, Python, C#,

113
00:05:23,400 --> 00:05:27,000
mutable objects are very common 
and honestly, sometimes they're 

114
00:05:27,000 --> 00:05:29,280
necessary or at least the most 
practical approach. 

115
00:05:29,280 --> 00:05:30,960
So it's not about total 
elimination. 

116
00:05:30,960 --> 00:05:32,960
No, not usually. 
The goal is more about 

117
00:05:32,960 --> 00:05:36,520
minimizing their number. 
Be deliberate, especially for 

118
00:05:36,520 --> 00:05:39,680
objects that represent simple 
values, rather than, say, 

119
00:05:39,680 --> 00:05:43,400
complex entities that genuinely 
have a life cycle where state 

120
00:05:43,400 --> 00:05:46,240
changes are fundamental. 
So as a practical guideline, 

121
00:05:46,400 --> 00:05:49,440
focus on making simple small 
objects immutable. 

122
00:05:49,920 --> 00:05:53,520
Think about value types objects,
where once you define it, the 

123
00:05:53,520 --> 00:05:55,600
value itself doesn't really 
change conceptually. 

124
00:05:55,800 --> 00:05:57,800
Like what? 
Well, source material gives 

125
00:05:57,800 --> 00:06:01,160
great examples. 
ZIP code, currency, address, 

126
00:06:01,320 --> 00:06:04,080
date, time, phone, color, 
e-mail, right? 

127
00:06:04,240 --> 00:06:06,640
If my adage just changes, I have
a new address, the old one 

128
00:06:06,640 --> 00:06:08,560
didn't morph into the new one. 
Exactly. 

129
00:06:08,840 --> 00:06:11,480
The previous address still 
existed, just as it was. 

130
00:06:11,920 --> 00:06:14,840
It's an immutable concept and 
languages are evolving to help 

131
00:06:14,840 --> 00:06:17,040
with this. 
Java, for instance, introduced 

132
00:06:17,040 --> 00:06:19,400
records back in version 16. 
Records. 

133
00:06:19,800 --> 00:06:22,080
Heard about those? 
They make creating these 

134
00:06:22,080 --> 00:06:24,320
immutable types much, much 
simpler. 

135
00:06:24,720 --> 00:06:28,320
You declare a record, say for a 
date with fields like day, 

136
00:06:28,320 --> 00:06:30,760
month, year. 
By default, those fields are 

137
00:06:30,760 --> 00:06:32,080
final. 
So immutable right 

138
00:06:32,080 --> 00:06:34,320
out-of-the-box. 
Pretty much it enforces it with 

139
00:06:34,320 --> 00:06:36,640
very little extra code needed 
from you. 

140
00:06:37,120 --> 00:06:40,080
Records also automatically give 
you essential methods like 

141
00:06:40,080 --> 00:06:43,600
toast, string, equals and hash 
code which are really important 

142
00:06:43,600 --> 00:06:46,160
for value objects. 
Saves a lot of boilerplate code.

143
00:06:46,200 --> 00:06:49,720
It does, and they even support 
validation right in the 

144
00:06:49,800 --> 00:06:52,400
constructor. 
So for that date record, you 

145
00:06:52,400 --> 00:06:55,160
could easily add checks to make 
sure the day is between 1 and 

146
00:06:55,160 --> 00:06:58,680
31, the month between 1:00 and 
12:00 right when the object is 

147
00:06:58,680 --> 00:07:00,840
created. 
So you encapsulate the 

148
00:07:00,840 --> 00:07:02,640
validation logic too. 
Exactly. 

149
00:07:02,640 --> 00:07:06,480
It's a really neat way to build 
robust, immutable value types 

150
00:07:06,600 --> 00:07:08,760
that add a lot of predictability
to your code. 

151
00:07:09,040 --> 00:07:12,080
That shift towards mutability 
offers so much clarity. 

152
00:07:12,760 --> 00:07:14,840
It really does. 
It makes me think about other 

153
00:07:14,840 --> 00:07:18,320
areas where our coding habits 
might hide deeper issues. 

154
00:07:18,640 --> 00:07:22,760
And Speaking of maybe counter 
intuitive insights, our next 

155
00:07:22,760 --> 00:07:26,080
code smell often catches people 
by surprise, even experienced 

156
00:07:26,080 --> 00:07:28,600
developers. 
This next one is data classes. 

157
00:07:29,080 --> 00:07:31,880
Now on the surface, these seem 
fine, maybe even convenient, 

158
00:07:31,880 --> 00:07:32,320
right? 
Yeah, they. 

159
00:07:32,480 --> 00:07:34,120
Look simple. 
We're talking about classes that

160
00:07:34,120 --> 00:07:36,720
mostly just hold data. 
They've got attributes, maybe 

161
00:07:36,720 --> 00:07:39,840
some basic getters and setters 
to access or change that data, 

162
00:07:40,120 --> 00:07:42,080
but not much else. 
No real behavior. 

163
00:07:42,080 --> 00:07:45,240
Just containers for data. 
Yeah, and for new programmers, 

164
00:07:45,240 --> 00:07:47,520
that's often the first kind of 
class they learn to write. 

165
00:07:48,160 --> 00:07:51,640
So if they're just holding data,
what's the smell? 

166
00:07:52,280 --> 00:07:54,200
And when is a data class not a 
spell? 

167
00:07:54,400 --> 00:07:57,400
Right, you've hit the key point.
Not every class that primarily 

168
00:07:57,400 --> 00:07:59,560
holds data is automatically a 
problem. 

169
00:07:59,560 --> 00:08:02,160
For example, a simple DTO data 
transfer object. 

170
00:08:02,160 --> 00:08:04,080
Used for moving data around. 
Exactly. 

171
00:08:04,120 --> 00:08:07,200
If it's only job is to shuttle 
data between layers or across 

172
00:08:07,200 --> 00:08:10,320
network boundaries, maybe it's 
fine being just data. 

173
00:08:10,680 --> 00:08:13,680
The smell really comes into play
when a data class is part of 

174
00:08:13,680 --> 00:08:17,280
your core domain model, but 
it's, well, anemic. 

175
00:08:17,440 --> 00:08:21,600
Yeah, an anemic domain model. 
It's a class that has the data, 

176
00:08:21,840 --> 00:08:23,680
but none of the associated 
behavior. 

177
00:08:24,120 --> 00:08:27,440
All the logic that operates on 
that data is scattered somewhere

178
00:08:27,440 --> 00:08:30,440
else in the system, maybe in 
service classes or utility 

179
00:08:30,440 --> 00:08:32,880
classes. 
I see the intelligence is 

180
00:08:32,880 --> 00:08:34,760
outside the object itself. 
Yes. 

181
00:08:35,280 --> 00:08:38,559
So the core recommendation when 
you spot this kind of data class

182
00:08:38,559 --> 00:08:43,039
smell is to analyze the code and
try to move behavior into the 

183
00:08:43,039 --> 00:08:45,240
class. 
Bring the logic closer to the 

184
00:08:45,240 --> 00:08:47,040
data it uses. 
Precisely. 

185
00:08:47,320 --> 00:08:50,600
Think about it, if you have a 
customer data class with first 

186
00:08:50,600 --> 00:08:53,000
name, last name, e-mail. 
But all the logic for checking 

187
00:08:53,000 --> 00:08:55,800
if the e-mail is valid, or 
generating a full name, or 

188
00:08:55,800 --> 00:08:58,040
sending a welcome e-mail is 
sitting in some separate 

189
00:08:58,040 --> 00:09:00,640
customer service class. 
That's often a sign of the 

190
00:09:00,640 --> 00:09:02,360
smell. 
Why is that considered bad 

191
00:09:02,360 --> 00:09:04,080
design? 
Well, it comes down to 

192
00:09:04,080 --> 00:09:07,080
fundamental principles like 
encapsulation and cohesion. 

193
00:09:07,440 --> 00:09:10,040
Encapsulation is about bundling 
data with the methods that 

194
00:09:10,040 --> 00:09:12,280
operate on it. 
Keeping related things together.

195
00:09:12,640 --> 00:09:15,960
Right, and cohesion is about how
well the responsibilities of a 

196
00:09:15,960 --> 00:09:19,000
single class or module fit 
together when the logic is 

197
00:09:19,000 --> 00:09:22,080
separate from the data. 
Both encapsulation and cohesion 

198
00:09:22,080 --> 00:09:25,200
suffer. 
By moving operations like is 

199
00:09:25,200 --> 00:09:28,520
valid e-mail or generate a full 
name directly into the customer 

200
00:09:28,520 --> 00:09:31,960
class itself, you make that 
customer object more 

201
00:09:31,960 --> 00:09:34,960
self-sufficient, more capable. 
It knows how to handle its own 

202
00:09:34,960 --> 00:09:35,960
data. 
Exactly. 

203
00:09:35,960 --> 00:09:38,760
It becomes the authority on its 
own state and behavior. 

204
00:09:39,080 --> 00:09:41,520
This also aligns with a 
principle called Tell, don't 

205
00:09:41,520 --> 00:09:42,240
ask. 
Tell. 

206
00:09:42,240 --> 00:09:45,240
Don't ask, Yeah. 
Instead of asking the customer 

207
00:09:45,240 --> 00:09:48,960
object for its raw data like 
e-mail, and then telling some 

208
00:09:48,960 --> 00:09:51,680
other service object what to do 
with that data like validate it,

209
00:09:52,000 --> 00:09:54,680
you just tell the customer 
object itself validate your 

210
00:09:54,680 --> 00:09:57,840
e-mail. 
OK, delegate the responsibility 

211
00:09:57,840 --> 00:09:59,480
to the object that owns the 
data. 

212
00:09:59,560 --> 00:10:01,520
Right. 
This generally makes the code 

213
00:10:01,520 --> 00:10:05,600
easier to understand, much 
easier to test in isolation, and

214
00:10:05,600 --> 00:10:08,640
easier to maintain because the 
functionality is logically 

215
00:10:08,640 --> 00:10:10,400
grouped with the data it 
manipulates. 

216
00:10:10,760 --> 00:10:13,400
That makes a lot of sense. 
It's like a ensuring the chef 

217
00:10:13,400 --> 00:10:15,920
has all their tools and 
ingredients right there instead 

218
00:10:15,920 --> 00:10:17,520
of running around the building 
for everything. 

219
00:10:17,880 --> 00:10:19,920
Centralizes the logic. 
Good analogy. 

220
00:10:19,960 --> 00:10:23,080
OK, now for our final code smell
today. 

221
00:10:23,640 --> 00:10:26,440
This one might genuinely 
surprise you, especially if you 

222
00:10:26,440 --> 00:10:29,240
learn programming being told to 
do the exact opposite all the 

223
00:10:29,240 --> 00:10:31,400
time. 
We're talking about comments. 

224
00:10:31,640 --> 00:10:35,680
Yes, comments in your code. 
Ha, yes, this one always raises 

225
00:10:35,680 --> 00:10:37,520
eyebrows. 
Right, the very thing new 

226
00:10:37,520 --> 00:10:41,120
programmers are often hammered 
to write comment everything can 

227
00:10:41,120 --> 00:10:45,360
sometimes be a code smell. 
So the big question is why? 

228
00:10:46,320 --> 00:10:48,920
Why would comments which seem 
like a good practice for 

229
00:10:48,920 --> 00:10:51,640
documentation actually be a 
smell? 

230
00:10:51,720 --> 00:10:55,080
It definitely feels counter 
intuitive at first, but it's 

231
00:10:55,080 --> 00:10:58,240
incredibly insightful once you 
grasp the underlying idea. 

232
00:10:58,240 --> 00:11:01,600
There's a classic piece of 
advice from Brian Kernighan and 

233
00:11:01,600 --> 00:11:04,880
PJ Plogger in their famous book 
Elements of Programming Style. 

234
00:11:05,400 --> 00:11:07,360
They put it very bluntly. 
Don't comment. 

235
00:11:07,360 --> 00:11:11,560
Bad code, Rewrite it. 
OK, straight to the point. 

236
00:11:11,640 --> 00:11:14,880
The core philosophy is actually 
quite simple, but powerful 

237
00:11:15,360 --> 00:11:18,600
comments should not be used as a
Band-Aid to explain messy, 

238
00:11:18,640 --> 00:11:22,320
unclear, or overly complex code.
So if the code is hard to 

239
00:11:22,320 --> 00:11:25,440
understand, the first instinct 
shouldn't be add a comment. 

240
00:11:25,600 --> 00:11:28,240
Exactly. 
If the code itself is confusing,

241
00:11:28,240 --> 00:11:31,800
the real solution isn't to write
an essay explaining it, it's to 

242
00:11:31,800 --> 00:11:36,000
refactor the code, improve it, 
make the code itself clearer. 

243
00:11:36,000 --> 00:11:39,280
Refactor first. 
Yes, restructure it, rename 

244
00:11:39,280 --> 00:11:42,480
variables and methods, better 
breakdown complex parts. 

245
00:11:42,720 --> 00:11:46,440
Once the code is genuinely clean
and clear, you often find that 

246
00:11:46,440 --> 00:11:48,960
the comments you thought you 
needed, well, they become 

247
00:11:48,960 --> 00:11:52,360
redundant because the code now 
explains itself effectively. 

248
00:11:52,600 --> 00:11:55,920
Let's take a common example. 
The long method smell often goes

249
00:11:55,920 --> 00:11:58,520
hand in hand with this. 
Imagine a method may be called 

250
00:11:58,520 --> 00:12:01,440
process order that does like 5 
different things inside it. 

251
00:12:01,480 --> 00:12:03,760
Yeah, I've seen plenty of those.
And often you'll see comments 

252
00:12:03,760 --> 00:12:06,240
inside it. 
Step one, validate input, then 

253
00:12:06,240 --> 00:12:09,160
some code, Step 2 check 
inventory, more code. 

254
00:12:09,400 --> 00:12:11,560
Step 3 calculate price. 
And so on. 

255
00:12:11,840 --> 00:12:13,200
Trying to make sense of the 
monolith. 

256
00:12:13,280 --> 00:12:15,120
Right, using comments as section
headers. 

257
00:12:15,240 --> 00:12:19,480
Precisely the presence of those 
internal divider comments is a 

258
00:12:19,480 --> 00:12:23,480
strong indicator, a smell that 
the method is probably too long 

259
00:12:23,480 --> 00:12:26,800
and doing too much. 
So the refactoring here is often

260
00:12:26,800 --> 00:12:29,840
something called extract method.
You take that block of code 

261
00:12:29,840 --> 00:12:33,080
under step one, validate input, 
and you pull it out into its own

262
00:12:33,080 --> 00:12:35,680
new method, maybe call it 
validate input. 

263
00:12:35,680 --> 00:12:37,640
OK, makes sense. 
You do the same for Step 2. 

264
00:12:37,640 --> 00:12:41,080
Maybe create a check inventory 
method and so on for each 

265
00:12:41,080 --> 00:12:43,240
logical block identified by 
those comments. 

266
00:12:43,240 --> 00:12:45,960
Breaking it down. 
Exactly what happens is your 

267
00:12:45,960 --> 00:12:48,880
original long process order 
method becomes much shorter. 

268
00:12:49,160 --> 00:12:52,800
It now just contains a sequence 
of calls to these new, clearly 

269
00:12:52,800 --> 00:12:57,080
named smaller methods. 
Validate input, check inventory,

270
00:12:57,480 --> 00:13:00,280
calculate price. 
So the structure becomes clear 

271
00:13:00,280 --> 00:13:02,200
just from the method calls. 
Precisely. 

272
00:13:02,400 --> 00:13:04,720
And after you've done this, 
refactor and what happens to 

273
00:13:04,720 --> 00:13:07,680
those original comments like 
step one, validate input. 

274
00:13:07,800 --> 00:13:10,600
They're not needed anymore. 
The method name validate input 

275
00:13:10,920 --> 00:13:12,600
tells you exactly what that call
does. 

276
00:13:12,640 --> 00:13:15,040
Exactly. 
The comments become redundant 

277
00:13:15,040 --> 00:13:18,120
because the code itself, through
good naming and structure, is 

278
00:13:18,120 --> 00:13:21,080
now self documenting. 
It really is a fascinating shift

279
00:13:21,080 --> 00:13:23,360
in mindset, isn't it? 
Instead of just explaining the 

280
00:13:23,360 --> 00:13:27,160
complexity that's there, the 
goal is to actively eliminate 

281
00:13:27,160 --> 00:13:28,680
the complexity in the first 
place. 

282
00:13:28,720 --> 00:13:31,440
That's the heart of it. 
This really highlights how 

283
00:13:31,440 --> 00:13:34,880
important refactoring is. 
It's not just clean up, it's a 

284
00:13:34,880 --> 00:13:38,480
core part of writing good 
software, turning code that 

285
00:13:38,480 --> 00:13:42,360
needs explanation into code that
just tells its own story. 

286
00:13:42,360 --> 00:13:43,280
Clearly. 
Well said. 

287
00:13:43,880 --> 00:13:46,520
That's the ideal. 
And that brings us to the end of

288
00:13:46,520 --> 00:13:49,800
our deep dive into these 
specific and I think really 

289
00:13:49,800 --> 00:13:53,000
intriguing code smells. 
Thank you for joining us on this

290
00:13:53,040 --> 00:13:56,080
exploration of the practical 
side of software engineering. 

291
00:13:56,080 --> 00:13:58,320
Yeah, good discussion. 
Hopefully this gives you some 

292
00:13:58,320 --> 00:14:01,240
useful perspectives on how we 
can make our software more 

293
00:14:01,240 --> 00:14:05,720
robust, more understandable, and
ultimately just more pleasant to

294
00:14:05,720 --> 00:14:07,360
work with. 
Thanks for tuning in.