Pratique du Shadowing: DRY Often Makes Your Code Worse - Apprendre l'anglais à l'oral avec la vidéo

Here's some example code for normalizing email addresses and usernames.

There's two functions here that do that job.

And I have a main function that has a bunch of email addresses and users and then normalizes them.

Winner on this, then this is what we get.

Now, obviously, this code has quite a bit of duplication, right?

If you take a look at these function bodies.

So, naturally, we should apply dry.

Don't repeat yourself and remove it.

Let's do that.

So first I'm going to create a new function called normalize strings.

And this is going to get a list of items.

And it will return a list of strings.

Now we just need to pass in the various options that control how these strings are being normalized.

So should there be an add symbol?

Is there a minimum length of the string?

And a couple of other things as well that we can all see from these two functions.

So let me paste that in here like so.

So these are all the options that we have.

Then inside the function we can create the result which will be a list of strings.

Initially that will be empty and in the end this is what we're going to return.

And then we can go over the items in the list of items.

And then for For example,

if strip white space, we're going to strip the item.

And if lowercase, we're going to turn it into lowercase.

And similarly, we can go through all of these different options

and do whatever we need to do in order to take care of those.

we're going to append the item to the result and then we can return it.

And now that we removed all of this nasty duplication, we can now replace these calls with our new function.

So instead of calling normalize email addresses, we can call normalize strings.

And then we just need to pass the email addresses.

So for an email address, the require at symbol needs to be there.

We also want to split the add symbol and we want to strip the mail prefix.

And that gives us our normalized emails.

Then I can do the same thing for usernames.

So also here, normalized strings.

And then I pass the usernames.

The minimum length should be 3.

There we go and we also want to remove the at prefix like so.

And now when I run this code again, we get exactly the same results.

So what happened here?

There's less duplication for sure.

I removed most of it, but the code has become way worse.

The behavior currently is impossible to understand.

There is all sorts of flags that interact in non-obvious ways.

Every new requirement now means that we need to add another parameter to this very generic function that doesn't repeat itself.

So I may have removed duplication, but I also turned the code into a hot mess.

So what actually happened here?

Now, before I show you what is actually the right way to refactor this,

what I've learned over the years is that it's not just important that you know how software design principles and patterns work.

It's also important that you understand the trade-offs that are behind them.

And that's exactly what I go deep into in software design mastery.

This is not just another course with patterns and principles.

It's a comprehensive system for thinking about architecture, boundaries, trade-offs, long-term maintainability.

If you want to become truly confident in your design decisions, join the waiting list at rnodecodes.mastery.

The link is also in the video description.

So what does this teach us about dry?

Well, don't repeat yourself doesn't mean that you should merge anything that looks similar into a one function.

It's actually more about not duplicating knowledge and knowledge in code is in things like data,

rules, business logic, those kinds of things.

Now in the battery factor that I just did I purely focused on how the code was shaped.

I looked at if statements for loops and things like that and then tried to remove all of that duplication.

If you want to improve code don't just blindly apply a principle like dry.

You actually need to understand the code.

So let's try this again but now let's focus on behavior and responsibilities.

So I just threw out the bad refactor that I did and I went back to the original code.

So this is again what it looks like.

Let's analyze what is happening here.

So first thing is that these normalized functions actually do two things.

One which is filtering.

For example here if there is not an ad in address it's simply not going to consider it.

But we see the same thing happening in the username.

So there is filtering and there is normalization.

Now if we don't focus too much on trying to remove all the duplication, we can actually start splitting out this logic more, which is what makes way more sense when you want to improve the code.

For example, for the filtering bit, we can use another function to check whether an email address is actually valid.

So let's say we have function isValidEmail.

Let's get some address.

And this is going to give us a boolean value that determines whether this address is actually valid.

And that is actually where we can use this check.

So here we're going to return that there is actually an add sign in the address.

And then now we can write it like this.

So now we moved some of the logic, and this is still pretty simple, but we moved some of logic outside of the function

which is nice and we can do the same thing for the usernames.

So here the length of the username should be more or equal than three like so.

But now that we've split out this logic, we can take a look at, for example, this function and see if we can focus the responsibility a bit more.

Because currently, this is responsible for checking that an email address is valid by calling this function.

It's responsible for looping through a list of addresses and then actually doing the normalization process.

So those are actually way too many responsibilities.

So let's split up the responsibilities.

And again, I'm not thinking about duplication at this moment.

I'm truly just thinking about how to organize this code better.

And if I have to write a few extra lines of code for that, I don't really care about it.

So instead of having this function that normalizes all the email address in the list and also checks whether emails are valid,

let's create another function called normalizeEmailAddress.

That does basically the normalization job for a single email address.

This normalizes the address and will return that as a string value.

So then we can basically take this part like so and I'll put it in here and then we can refactor that.

So this actually should not be part of email address normalization.

So the first step is removing whitespace and turning it into a lowercase.

Then we get the local part and the domain.

100

We remove the prefix from the domain and then we're simply going to return this as a result.

101

So this is our normalize email address function.

102

And now actually normalize email addresses can be very simple.

103

Because we don't need all of this complication here.

104

We can even make this a lot shorter and just use a list comprehension.

105

And there we check if the email address is valid.

106

So now we turn this complicated function into something that's way simpler.

107

And for usernames we can do the same thing.

108

So here I'm also simply copying this, putting it in here.

109

We don't need the valid check here.

110

And I can simply return this as a result.

111

don't need to store it here.

112

And then also here in normalized usernames I can simply use a list comprehension.

113

Like so.

114

Let's run this to check whether this still works as expected.

115

Now when you take a look at this version of the code actually I didn't remove all the duplication

116

because that wasn't the focus I didn't focus on trying to remove duplication

117

and actually there is still duplication in here like normalizing email

118

addresses well this code looks a lot like normalizing the usernames

119

except it calls slightly different functions now you could decide to abstract

120

that away and make like a filter and process function

121

or something like that if you really wanted to but honestly to me this isn't that bad that there is some duplication.

122

However I did remove the right duplication in the sense

123

that validation rules like these kind of checks are now in a single place

124

and normalization rules are also in a single place

125

because they're grouped in these functions now they're not all mixed up

126

and by doing this it means that our control flow stays simple

127

and still readable even though there is still some duplication

128

and actually in many cases having some duplication in code is good these loops

129

or list comprehensions I don't really mind

130

that they're duplicated it's they're pretty cheap it's not many lines of code it's easy to read

131

but more importantly duplication can sometimes help you enforce boundaries for

132

example you may also encounter duplication sometimes in your api right

133

you might have a database schema you might have an api output schema these are going to be very similar

134

so you might be tempted to use the same object for

135

that maybe if you're using sql model or something but that couples your API directly to your database, your persistent layer.

136

By keeping them separate you avoid leaking database concerns into your API

137

and it gives you flexibility to evolve each of these independently.

138

So there is some duplication in that case there but repeating yourself is actually protecting your design in that case.

139

So overall when you're working on code like this I'd say prefer duplication over the wrong way of abstracting things.

140

Look for duplicated rules not duplicated loops and try to fix those.

141

If you notice

142

that you need to add a bunch of flags in order

143

to remove the duplication from the code that's probably a red flag, pun intended.

144

So instead focus on truly understanding the code.

145

You'll be way better at organizing the code more effectively.

146

And what I typically do when I write code whether that's me

147

or some AI coding agent is

148

that I start writing I don't really think about how it looks I copy things around

149

when I need them but when I notice

150

that there is actually duplicated rules then I might abstract things away

151

so abstraction is a consequence of writing the code

152

and copying things around I don't start there

153

when using a tool like cloud code you can just let it write all the code

154

but then you do need to take that step of understanding the code

155

that it grows and seeing if you can abstract away a couple of things

156

and by the way

157

if you enjoy these types of design videos give a video

158

a like subscribe to the channel it helps me reach more people here on youtube

159

so finally dry don't repeat yourself is not a wrong principle

160

but it's really easy to misuse it's easy to think

161

that you should somehow not have any duplication in the logic That's not what it means.

162

The key thing is that you understand the code and

163

that you abstract away the right things so that they're properly separated and that knowledge, data, business logic is not duplicated in your code.

164

If you do it blindly, just start refactoring and moving things around, you'll often end up in a worse place.

165

You need to understand it and that leads to better abstractions.

166

But I'd like to hear what you think.

167

Do you apply the dry principle yourself to code?

168

Do you tend to over abstract things or do you tend to keep duplication around much longer?

169

Have you ever tried to refactor something removing duplication and it completely backfires?

170

Let me know in the comments.

171

Now, if you want to explore more software design videos, check out my design patterns playlist right here.

172

Thanks for watching and see you next time.

Qu'est-ce que la technique du Shadowing ?

Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.

Pratique du Shadowing: DRY Often Makes Your Code Worse - Apprendre l'anglais à l'oral avec la vidéo

Context & Background

Top 5 Phrases for Daily Communication

Step-by-step Shadowing Guide

Qu'est-ce que la technique du Shadowing ?