शैडोइंग अभ्यास: DRY Often Makes Your Code Worse - वीडियो के साथ अंग्रेजी बोलना सीखें

अभ्यास मोड चुनें

हर मोड पूरी स्क्रीन का अभ्यास कक्ष खोलता है।

172 वाक्य

यदि वाक्य बहुत छोटे या लंबे हों, तो समायोजित करने के लिए Edit पर क्लिक करें।

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.

ऐप डाउनलोड करें

धाराप्रवाह बोलने के लिए ज़रूरी सब कुछ

AI उच्चारण स्कोरहर वाक्य का स्कोर

IPA अभ्यासहर ध्वनि में महारत

शब्दावलीअपना शब्द भंडार बनाएँ

शब्द गेमखेलते हुए सीखें

QR स्कैन करें

Download on theApp Store Get it onGoogle Play

उसी चैनल से

Your API Can’t Handle Real-World Integrations

Business EnglishUniversity StudentsWorking Adults

FOR YOU

अनुशंसित वीडियो

The 7 Habits of Highly Successful Students (Part 6) 💯

3,084

11 वाक्य

इस पाठ के बारे में

इस पाठ में, आप कोडिंग के एक महत्वपूर्ण सिद्धांत "DRY" यानी "Don't Repeat Yourself" के बारे में सीखेंगे। आप सीखेंगे कि कैसे कुछ कार्यों में बार-बार कोड को दोहराने से बचा जा सकता है, और इसके स्थान पर और अधिक स्वच्छ और सुगठित कोड लिखा जा सकता है। यह वीडियो उन समझौतों की भी चर्चा करता है जो इस सिद्धांत के पीछे हो सकते हैं, जिससे आपकी समझ और भी गहरी होगी।

मुख्य शब्दावली और वाक्यांश

DRY: यह सिद्धांत कोड को दोहराने से बचने के लिए है।
normalize strings: स्ट्रिंग्स को सामान्य रूप में लाने का कार्य।
white space: खाली स्थान, जो कि कई बार कोड में समस्या पैदा कर सकता है।
lowercase: अक्षरों को छोटे अक्षरों में बदलना।
parameters: कार्य में आवश्यक विकल्प या तत्व।
refactor: कोड को बेहतर तरीके से व्यवस्थित करना।
flags: विशेष विकल्प जो कार्य के व्यवहार को प्रभावित कर सकते हैं।

अभ्यास टिप्स

आप इस वीडियो में प्रस्तुत सिद्धांतों और तकनीकों को प्रभावी ढंग से सीखने के लिए शैडोइंग साइट का उपयोग कर सकते हैं। जब आप इस वीडियो का पालन करते हैं, तो अपने उच्चारण पर ध्यान दें। वीडियो की गति धीमी होती है, इसलिए इसका अनुसरण करना आसान होगा। आप shadowspeak तकनीक का उपयोग करें: पहले वीडियो को ध्यान से सुनें, फिर उसे दोहराएं। यह आपको अंग्रेजी उच्चारण में सुधार में मदद करेगा। जब आप व्याख्यान का अनुसरण करते हैं, तो हर वाक्यांश के बाद रुकें और उसे सुनें, फिर पूरी तरह से उसे पुनः प्रस्तुत करें। इस प्रकार से आप केवल सुनने ही नहीं, बल्कि बोलने का अभ्यास भी कर रहे हैं। अपनी गति को धीमा रखें और पूरी स्पष्टता के साथ बोलने का प्रयास करें।

यह न केवल आपकी भाषाई क्षमताओं को सुधारने में मदद करेगा, बल्कि आपके आत्मविश्वास को भी बढ़ाएगा।

इस वीडियो का व्याकरण

वक्ता जिन संरचनाओं का सबसे अधिक प्रयोग करता है, वीडियो के असली शब्दों के साथ:

संरचना	वीडियो में
Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी है	has become · I've learned · we've split
Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता है	being normalized · was shaped · might be tempted
Relative clauses who / which + उपवाक्य — व्यक्ति या वस्तु के बारे में अतिरिक्त जानकारी	result which will · One which is · more, which is

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।

शैडोइंग तकनीक: पूरी चरण-दर-चरण गाइड पढ़ें →

शैडोइंग अभ्यास: DRY Often Makes Your Code Worse - वीडियो के साथ अंग्रेजी बोलना सीखें

अभ्यास मोड चुनें

ऐप डाउनलोड करें

Your API Can’t Handle Real-World Integrations

The 7 Habits of Highly Successful Students (Part 6) 💯

You are wasting memory

Are we heading to an era of stagnation or innovation?

The easy way to keep your repos tidy.

Every Networking Concept Explained In 20 Minutes

Use these CSS features instead of JavaScript

10 Unspoken Rules Nordic People Ignore To Keep Life Simple

The 3-Step System for Simplifying Your Work and Life

My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It

System Design Was HARD - Until You Knew the Trade-Offs

I’m Begging You: Replace Scrolling With These Habits

Daily Stand-up Meeting in English | Listening Practice for Developers | Ep. 1

इस पाठ के बारे में

मुख्य शब्दावली और वाक्यांश

अभ्यास टिप्स

इस वीडियो का व्याकरण

शैडोइंग तकनीक क्या है?