1
00:00:00,040 --> 00:00:03,320
Welcome back to the Deep Dive. 
You know, we often tackle these 

2
00:00:03,320 --> 00:00:07,360
big complex topics, especially 
in tech, trying to cut through 

3
00:00:07,360 --> 00:00:09,280
the noise. 
Yeah, there's just so much 

4
00:00:09,280 --> 00:00:11,080
information out there. 
Exactly. 

5
00:00:11,360 --> 00:00:14,840
And today we're diving in 
something really practical 

6
00:00:15,000 --> 00:00:17,320
refactoring practice. 
We're not just going to talk 

7
00:00:17,320 --> 00:00:21,280
theory like what is refactoring.
No, the goal here is how it's 

8
00:00:21,280 --> 00:00:23,400
actually done. 
You know, in real software 

9
00:00:23,400 --> 00:00:26,040
projects, day-to-day. 
Right, drawing from our source 

10
00:00:26,040 --> 00:00:30,800
material, and the first thing 
that jumps out like immediately 

11
00:00:30,800 --> 00:00:33,280
is this absolute reliance on 
good tests. 

12
00:00:33,320 --> 00:00:35,040
Oh, absolutely. 
It's foundational. 

13
00:00:35,160 --> 00:00:37,240
Seriously, the sources say it's 
just non negotiable. 

14
00:00:37,680 --> 00:00:40,560
OK, let's unpack this a bit. 
Well, it's fascinating because 

15
00:00:40,720 --> 00:00:43,560
tests, especially unit tests, 
aren't just helpful for 

16
00:00:43,560 --> 00:00:45,680
refactoring, they're kind of 
essential. 

17
00:00:45,880 --> 00:00:47,640
They make it possible in the 
first place. 

18
00:00:47,640 --> 00:00:49,760
How so exactly? 
Because remember what 

19
00:00:49,760 --> 00:00:52,240
refactoring is. 
You're changing the code's 

20
00:00:52,240 --> 00:00:55,400
internal structure. 
You're not adding features, 

21
00:00:55,400 --> 00:00:58,040
you're not fixing bugs in the 
sense of changing what it does 

22
00:00:58,040 --> 00:00:59,000
externally. 
Right. 

23
00:00:59,000 --> 00:01:01,360
You're cleaning it up, making it
better internally. 

24
00:01:01,600 --> 00:01:04,440
Precisely. 
But changing code is inherently 

25
00:01:04,440 --> 00:01:06,560
risky, right? 
How do you know you didn't 

26
00:01:06,560 --> 00:01:09,280
accidentally break some, 
especially if you're not 

27
00:01:09,280 --> 00:01:11,160
changing the observable 
behavior? 

28
00:01:11,360 --> 00:01:13,400
OK. 
So the tests are the safety net.

29
00:01:13,800 --> 00:01:16,000
Exactly that. 
They're the only way you can 

30
00:01:16,000 --> 00:01:19,160
verify that the external 
behavior, the thing the user or 

31
00:01:19,160 --> 00:01:22,920
other parts of the system rely 
on, hasn't changed after your 

32
00:01:22,920 --> 00:01:25,880
internal tweaks. 
Without that net, it's just too 

33
00:01:25,880 --> 00:01:28,520
dangerous to make significant 
structural changes that makes. 

34
00:01:28,520 --> 00:01:30,320
Sense. 
Yeah, and John Aster outputs it 

35
00:01:30,320 --> 00:01:31,240
really well. 
He says. 

36
00:01:31,840 --> 00:01:35,160
Tests, particularly unit tests, 
play an important role in design

37
00:01:35,160 --> 00:01:38,040
because they facilitate 
refactoring, he goes on. 

38
00:01:38,240 --> 00:01:40,720
Without a test suite, it's 
dangerous to make major 

39
00:01:40,720 --> 00:01:43,440
structural changes to a system. 
And the consequence? 

40
00:01:44,000 --> 00:01:47,200
As a result, developers avoid 
refactoring in a system without 

41
00:01:47,200 --> 00:01:49,480
good test suites. 
They just leave the messy code 

42
00:01:49,480 --> 00:01:50,800
alone. 
Exactly. 

43
00:01:51,160 --> 00:01:54,320
They try to minimize the number 
of code changes for each new 

44
00:01:54,320 --> 00:01:58,480
feature or bug fix, which means 
that complexity accumulates and 

45
00:01:58,480 --> 00:02:00,560
design mistakes don't get 
corrected. 

46
00:02:00,560 --> 00:02:04,520
Wow, so no tests means 
complexity just grows? 

47
00:02:04,520 --> 00:02:07,160
It actively prevents you from 
improving the design. 

48
00:02:07,160 --> 00:02:10,120
You get trapped. 
So that's the aha moment, right?

49
00:02:10,199 --> 00:02:12,720
You're not adding features, 
you're not fixing external bugs,

50
00:02:13,200 --> 00:02:16,560
but the tests are arguably more 
important here. 

51
00:02:16,680 --> 00:02:19,120
In a way, yes. 
They give you the confidence, 

52
00:02:19,120 --> 00:02:21,720
the courage really to make those
improvements. 

53
00:02:21,720 --> 00:02:24,160
It's the guard reel. 
It lets you clean up the engine 

54
00:02:24,160 --> 00:02:27,120
while the car is still running. 
Basically, without it you just 

55
00:02:27,120 --> 00:02:28,720
wouldn't dare touch certain 
things. 

56
00:02:28,800 --> 00:02:31,720
Perfectly put. 
You avoid the snowball effect of

57
00:02:31,720 --> 00:02:33,760
complexity because you have that
safety. 

58
00:02:33,880 --> 00:02:37,160
OK, so tests are the absolute 
bedrock. 

59
00:02:37,600 --> 00:02:40,920
Assuming you have those, the 
next big question is when do you

60
00:02:40,920 --> 00:02:43,920
actually do this refactoring? 
Right, because developers are 

61
00:02:43,920 --> 00:02:45,400
always busy. 
Deadlines. 

62
00:02:45,400 --> 00:02:47,520
New features. 
Yeah, you can't just stop 

63
00:02:47,520 --> 00:02:48,800
everything all the time. 
Yeah. 

64
00:02:49,160 --> 00:02:53,200
So our sources point to two main
ways this happens. 

65
00:02:53,200 --> 00:02:55,440
And here's where it gets really 
interesting. 

66
00:02:55,440 --> 00:02:57,920
Yeah, it does. 
The first one, and probably the 

67
00:02:57,920 --> 00:03:00,720
most common, is what's called 
opportunistic refactoring. 

68
00:03:00,720 --> 00:03:03,560
Opportunistic. 
OK, so this is stuff you do like

69
00:03:03,560 --> 00:03:05,480
while you're already working on 
something else. 

70
00:03:05,840 --> 00:03:09,840
Say you're fixing a bug or 
adding a small feature and you 

71
00:03:09,840 --> 00:03:12,680
notice something. 
Maybe a method name is really 

72
00:03:12,680 --> 00:03:16,680
unclear or a function has gotten
way too long and complicated. 

73
00:03:16,680 --> 00:03:18,280
Or code that isn't even used 
anymore. 

74
00:03:18,280 --> 00:03:21,520
Exactly. 
Dead code, overly complex logic.

75
00:03:21,640 --> 00:03:23,360
You spot it while you're there 
anyway. 

76
00:03:23,440 --> 00:03:27,120
And you just fix it right then. 
Yes, you take a few extra 

77
00:03:27,120 --> 00:03:29,720
minutes, maybe longer depending 
on the issue, and you clean it 

78
00:03:29,720 --> 00:03:33,320
up right then and there. 
Rename the confusing thing, 

79
00:03:33,800 --> 00:03:36,800
breakdown the long method, 
delete the dead code. 

80
00:03:37,000 --> 00:03:40,040
It's like that Boy Scout rule. 
Leave the code cleaner than you 

81
00:03:40,040 --> 00:03:41,200
found it. 
Precisely. 

82
00:03:41,200 --> 00:03:44,120
It's about continuous 
improvement baked into the daily

83
00:03:44,120 --> 00:03:46,080
workflow. 
And the source material actually

84
00:03:46,080 --> 00:03:48,680
gives some practical advice 
here, doesn't it? 

85
00:03:48,680 --> 00:03:50,200
Like a rule of thumb. 
It does. 

86
00:03:50,200 --> 00:03:53,120
It suggests that if you're 
spending, say, an hour on a 

87
00:03:53,120 --> 00:03:57,200
task, maybe dedicate 20% or even
more of that time to these 

88
00:03:57,200 --> 00:04:00,320
small, opportunistic cleanups. 
So it's not seen as separate 

89
00:04:00,320 --> 00:04:02,560
work, but part of the task 
itself. 

90
00:04:02,600 --> 00:04:05,880
Right, it's an investment. 
It makes the code base easier to

91
00:04:05,880 --> 00:04:08,440
work with next time for you or 
someone else. 

92
00:04:08,720 --> 00:04:12,280
It prevents that technical debt 
from piling up quite so fast. 

93
00:04:12,280 --> 00:04:15,840
It makes a lot of sense. 
And this ties into Kent Beck's 

94
00:04:15,840 --> 00:04:19,079
famous idea. 
He said for each desired change,

95
00:04:19,160 --> 00:04:22,520
make the change easy. 
Warning this may be hard. 

96
00:04:22,800 --> 00:04:25,120
Then make the easy change. 
OK, unpack that a little. 

97
00:04:25,120 --> 00:04:27,160
Make the change easy. 
Sometimes you want to add a 

98
00:04:27,160 --> 00:04:30,880
feature or fix a bug, but the 
current code structure makes it 

99
00:04:30,880 --> 00:04:33,040
really awkward, really 
difficult. 

100
00:04:33,160 --> 00:04:35,360
You're fighting the code. 
We've all been there. 

101
00:04:35,480 --> 00:04:39,360
Right, so instead of just 
forcing it in, Beck suggests you

102
00:04:39,360 --> 00:04:41,160
first refactor the existing 
code. 

103
00:04:41,400 --> 00:04:44,440
You change the structure to make
easy to add your feature or fix 

104
00:04:44,440 --> 00:04:47,360
your bug. 
So you do a preparatory cleanup.

105
00:04:47,360 --> 00:04:49,360
Exactly. 
You take maybe one step back 

106
00:04:49,360 --> 00:04:52,440
refactoring so that you can then
take two steps forward easily. 

107
00:04:52,640 --> 00:04:55,920
The actual change becomes 
trivial once the structure is 

108
00:04:55,920 --> 00:04:57,720
right. 
So that difficult task might 

109
00:04:57,720 --> 00:04:59,880
become super simple after the 
refactoring. 

110
00:04:59,880 --> 00:05:03,160
Often, yeah. 
And this opportunistic approach,

111
00:05:03,240 --> 00:05:06,840
including Beck's idea, probably 
covers most refactoring that 

112
00:05:06,840 --> 00:05:08,840
happens. 
It's the day in, day out 

113
00:05:08,840 --> 00:05:10,880
practice. 
OK, so that's the constant low 

114
00:05:10,880 --> 00:05:13,280
level cleanup. 
But sometimes, sometimes you 

115
00:05:13,280 --> 00:05:14,680
need more, right? 
What if things have gotten 

116
00:05:14,680 --> 00:05:17,040
really out of hand or you need a
major overhaul? 

117
00:05:17,320 --> 00:05:19,480
Right, that's where the second 
approach comes in. 

118
00:05:19,880 --> 00:05:21,760
Planned refactorings. 
Planned. 

119
00:05:21,880 --> 00:05:23,880
OK, sounds more deliberate. 
It is. 

120
00:05:23,920 --> 00:05:26,480
These are the bigger, more time 
consuming changes. 

121
00:05:27,080 --> 00:05:29,840
Thing is, you really can't just 
squeeze into a regular task. 

122
00:05:30,040 --> 00:05:33,400
They often need dedicated time, 
maybe planning, sometimes 

123
00:05:33,400 --> 00:05:35,760
involving the whole team. 
Can you give an example? 

124
00:05:35,920 --> 00:05:39,120
Sure. 
A classic one is maybe you have 

125
00:05:39,120 --> 00:05:42,840
a really large software module 
or package that's just become a 

126
00:05:42,840 --> 00:05:46,560
monolith doing too many things. 
A planned refactoring might be 

127
00:05:46,560 --> 00:05:49,560
to break that down into several 
smaller, more focused 

128
00:05:49,560 --> 00:05:52,040
subtackages. 
That sounds like a significant 

129
00:05:52,040 --> 00:05:53,720
effort. 
It definitely can be. 

130
00:05:53,880 --> 00:05:57,400
Or another situation. 
Maybe a team realizes they've, 

131
00:05:57,520 --> 00:05:59,560
you know, neglected refactoring 
for too long. 

132
00:05:59,960 --> 00:06:02,680
Technical debt is high. 
They might actually schedule 

133
00:06:02,680 --> 00:06:05,280
specific time, like a 
refactoring week or dedicated 

134
00:06:05,280 --> 00:06:08,680
days just to tackle the backlog 
of needed improvements. 

135
00:06:08,720 --> 00:06:11,320
So it's a strategic decision to 
invest focused time. 

136
00:06:11,520 --> 00:06:13,600
Exactly. 
It's for those larger structural

137
00:06:13,600 --> 00:06:17,000
changes, or when you need a 
concerted effort to pay down 

138
00:06:17,000 --> 00:06:21,080
significant technical debt that 
opportunistic cleanups just 

139
00:06:21,120 --> 00:06:23,760
aren't addressing. 
It's often necessary for like, 

140
00:06:24,240 --> 00:06:27,760
enabling future big changes or 
improving overall system health.

141
00:06:27,880 --> 00:06:30,920
Got it. 
So understanding when to use 

142
00:06:30,920 --> 00:06:34,760
which approach, the ongoing 
opportunistic tweaks versus the 

143
00:06:34,760 --> 00:06:37,920
focused planned efforts, that's 
really key to keeping code 

144
00:06:37,920 --> 00:06:39,680
manageable in the long run. 
Absolutely. 

145
00:06:39,680 --> 00:06:42,480
It's about balancing immediate 
cleanup with strategic 

146
00:06:42,480 --> 00:06:44,520
investment. 
OK, this brings us to something 

147
00:06:44,520 --> 00:06:47,080
that's, well, kind of changed 
the game for refactoring, 

148
00:06:47,600 --> 00:06:52,000
automation, modern tools, the ID
ES, they help a lot here, right?

149
00:06:52,560 --> 00:06:54,240
Massively. 
It's hard to overstate the 

150
00:06:54,240 --> 00:06:56,160
impact. 
Automated refactoring tools 

151
00:06:56,160 --> 00:06:58,880
built into integrated 
development environments or ID 

152
00:06:58,880 --> 00:07:02,520
ES are incredibly powerful. 
How do they actually work? 

153
00:07:02,520 --> 00:07:05,840
Is it just magic? 
Not quite magic, but it feels 

154
00:07:05,840 --> 00:07:08,000
like it's sometimes. 
So imagine you want to rename a 

155
00:07:08,000 --> 00:07:09,520
method. 
Let's say it's used in, I don't 

156
00:07:09,520 --> 00:07:11,760
know, 50 different places across
your code base. 

157
00:07:11,760 --> 00:07:14,880
So that manually would be 
tedious and risky. 

158
00:07:14,920 --> 00:07:17,680
You'd miss one for sure. 
For sure, with an IDE you 

159
00:07:17,680 --> 00:07:20,640
typically just select the method
name, choose the rename 

160
00:07:20,640 --> 00:07:24,440
refactoring option, type in the 
new name and hit enter and then 

161
00:07:24,560 --> 00:07:26,760
and then. 
The IDE automatically finds 

162
00:07:26,760 --> 00:07:29,880
every single place that method 
is called or referenced and 

163
00:07:29,880 --> 00:07:33,040
updates it to the new name 
instantly and accurately. 

164
00:07:33,640 --> 00:07:36,240
And it's not just renaming. 
It works for things like 

165
00:07:36,240 --> 00:07:40,120
extracting a piece of code into 
its own new method, changing the

166
00:07:40,120 --> 00:07:43,880
parameters of a function, 
introducing variables, lots of 

167
00:07:43,880 --> 00:07:47,600
common refactoring tasks. 
The tool handles the widespread 

168
00:07:47,600 --> 00:07:50,840
mechanical changes. 
That sounds amazing, but you 

169
00:07:50,840 --> 00:07:52,640
said it's not magic, so what's 
the catch? 

170
00:07:52,720 --> 00:07:54,640
Or rather, what's the developer 
still doing? 

171
00:07:54,800 --> 00:07:56,320
Well, the developer's still 
driving. 

172
00:07:56,320 --> 00:07:58,680
You have to identify what needs 
refactoring. 

173
00:07:58,840 --> 00:08:01,040
You have to decide which 
refactoring operation makes 

174
00:08:01,040 --> 00:08:03,600
sense, Rename, extract method 
etcetera. 

175
00:08:03,760 --> 00:08:06,160
You have to provide the 
necessary information like the 

176
00:08:06,160 --> 00:08:08,520
new name or how the new method 
should look. 

177
00:08:08,520 --> 00:08:11,880
So the intelligence, the design 
decision, is still human. 

178
00:08:12,040 --> 00:08:15,440
Absolutely. 
The IDE is the incredibly smart,

179
00:08:15,440 --> 00:08:18,880
incredibly fast assistant doing 
the mechanical work. 

180
00:08:19,360 --> 00:08:22,680
And crucially, before it does 
the work, it checks things. 

181
00:08:22,680 --> 00:08:25,080
It runs what are called 
precondition checks. 

182
00:08:25,080 --> 00:08:27,360
Preconditions like safety check.
Exactly. 

183
00:08:27,760 --> 00:08:31,360
It analyzes the code to make 
sure the requested refactoring 

184
00:08:31,360 --> 00:08:34,720
won't, for example, break the 
build, cause compilation errors,

185
00:08:34,720 --> 00:08:37,960
or accidentally change the 
program's behavior in unintended

186
00:08:37,960 --> 00:08:40,799
ways. 
If it detects a problem, it'll 

187
00:08:40,799 --> 00:08:43,159
usually warn you or prevent the 
refactoring. 

188
00:08:43,679 --> 00:08:46,320
So it adds another layer of 
safety on top of the test we 

189
00:08:46,320 --> 00:08:47,680
talked about earlier. 
It does. 

190
00:08:47,680 --> 00:08:50,040
It makes the process much safer 
and way more efficient, 

191
00:08:50,040 --> 00:08:52,920
especially for changes that 
affect many parts of the code. 

192
00:08:53,280 --> 00:08:55,880
But yeah, the human intent, the 
why and the what, that's still 

193
00:08:55,880 --> 00:08:58,480
firmly with the developer, so. 
It's a powerful partnership, 

194
00:08:58,720 --> 00:09:01,560
human intelligence guiding 
sophisticated automation. 

195
00:09:01,680 --> 00:09:05,040
That's a great way to put it. 
OK, so wrapping things up for 

196
00:09:05,040 --> 00:09:08,560
this deep dive on retract during
practice, we've seen how 

197
00:09:08,560 --> 00:09:10,680
absolutely crucial good tests 
are. 

198
00:09:10,920 --> 00:09:12,760
They're the foundation for doing
this safely. 

199
00:09:13,080 --> 00:09:15,000
Couldn't agree more. 
Non negotiable. 

200
00:09:15,160 --> 00:09:18,200
Then we looked at the 2 main 
timings, the everyday 

201
00:09:18,680 --> 00:09:21,520
opportunistic cleanups. 
Keeping things tidy as you go. 

202
00:09:21,520 --> 00:09:25,560
And the more strategic planned 
refactoring efforts for bigger 

203
00:09:25,560 --> 00:09:28,680
changes or tackling debt. 
Right, the larger investments. 

204
00:09:29,080 --> 00:09:33,000
And finally, the huge role 
automation plays now through ID 

205
00:09:33,000 --> 00:09:36,640
ES, making these changes safer 
and much much faster, while 

206
00:09:36,640 --> 00:09:38,560
still relying on the developer's
judgement. 

207
00:09:38,600 --> 00:09:41,600
Yeah, the tools really enable a 
lot more refactoring than was 

208
00:09:41,600 --> 00:09:43,720
practical before. 
It gives you a much clearer 

209
00:09:43,720 --> 00:09:47,240
picture of how healthy code 
bases are actually maintained in

210
00:09:47,240 --> 00:09:49,560
the real world. 
It's not just about writing new 

211
00:09:49,560 --> 00:09:52,280
code, but constantly refining 
what's already there. 

212
00:09:52,280 --> 00:09:54,920
It's a continuous process. 
Well, thank you for joining us 

213
00:09:54,920 --> 00:09:55,720
on this deep dive.