Vox

Leitura de 16 min

Rejecting the DRY Principle

Summary

This episode challenges the conventional wisdom of the DRY (Don’t Repeat Yourself) principle in programming. The host argues that while DRY is generally good advice for creating reusable code, there are important exceptions where repeating yourself can be beneficial.

The first exception discussed is during the initial coding phase when you’re still trying to understand the problem. The host references Sandy Metz’s approach of repeating yourself before refactoring, suggesting that duplicating code while exploring a solution can lead to better abstractions later. This process allows developers to see patterns more clearly before committing to a specific implementation.

Another key exception is when making code DRY would create overly complex or overly flexible abstractions. The host argues that sometimes duplicated code is actually easier to maintain than a single abstraction that tries to handle too many variations. When abstractions become too complex, they can be harder to understand and modify than simpler duplicated code.

The episode emphasizes the importance of questioning programming dogmas and understanding the context behind best practices. The host encourages developers to weigh the trade-offs between code duplication and abstraction complexity, suggesting that in some cases, repeated code is preferable to complex code that’s difficult to understand and modify.

Throughout the discussion, the host maintains that DRY remains a valuable guideline but shouldn’t be followed blindly. The key insight is that developers should understand why principles exist and when exceptions might apply, rather than applying rules without consideration for the specific context and maintainability concerns.

Recommendations

Books

  • Practical Object Oriented Design with Ruby — Recommended by the host as a resource for understanding programming principles that apply across languages, particularly Sandy Metz’s approach to code duplication and refactoring.

Educational-Platforms

  • CodeSchool — Sponsored educational platform mentioned throughout the episode offering programming courses in various languages and topics, with several free courses available.

People

  • Sandy Metz — Referenced multiple times for her insights on when to repeat code before refactoring and her approach to object-oriented design principles.

Topic Timeline

  • 00:00:00 — Introduction to questioning DRY principle — Jonathan introduces the episode’s topic about challenging the ‘Don’t Repeat Yourself’ principle. He explains that while DRY is generally good advice for creating reusable code, there are exceptions where repeating yourself can be beneficial, especially for understanding code during development.
  • 00:01:25 — First exception: Understanding through repetition — The host discusses the first major exception to DRY - repeating yourself while trying to understand code. He references Sandy Metz’s approach of duplicating code during initial development before refactoring. This allows developers to see patterns and understand the problem better before creating abstractions.
  • 00:05:51 — Sponsor segment: CodeSchool — Jonathan promotes CodeSchool as the episode’s sponsor, highlighting their programming courses including Ruby, JavaScript, HTML, CSS, and specialized topics like regular expressions, R programming, Google Drive API, and Chrome DevTools. He mentions that several courses are available for free.
  • 00:07:21 — Second exception: Avoiding overly complex abstractions — The host discusses the second exception - when making code DRY creates overly complex or flexible abstractions. He argues that sometimes duplicated code is easier to maintain than a single abstraction that tries to handle too many variations. The key insight is that it’s better to have repeated code than complex code that’s difficult to understand.
  • 00:11:50 — Conclusion and call to question assumptions — Jonathan concludes by encouraging developers to question programming principles and understand their context. He emphasizes that DRY should be a guideline rather than an absolute rule, and developers should weigh the trade-offs between duplication and complexity based on their specific situation and maintainability concerns.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-08-24T07:00:00Z
  • Duration: 00:13:37

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I’m

[00:00:06] going to be talking to you about not repeating yourself and how that’s not always the best

[00:00:12] idea. Today’s episode is sponsored by CodeSchool. You can check out CodeSchool at codeschool.com

[00:00:21] of course and I’ll be talking a little bit more about them later in the show. But if

[00:00:25] you want to learn how to code and especially if you are at the very beginning of your career

[00:00:31] or you’re trying to learn a specific new topic, go and check out codeschool.com. I’ll be sharing

[00:00:37] a few more details about how to get some incentives, especially for Developer Tea listeners.

[00:00:45] But I want to jump into today’s topic and believe it or not, it is actually kind of

[00:00:50] an advanced topic. And it’s advanced because so many times as young developers, we’ve been

[00:00:55] hearing, don’t repeat yourself. And this is good advice in general because it teaches

[00:01:02] us to turn things that we do over and over into reusable chunks of code. How many times

[00:01:10] have you, for example, if you’re a Rails developer, created a partial to hold part of your views?

[00:01:17] And this is not just for Rails developers, there’s partials in all kinds of frameworks.

[00:01:21] But sometimes this isn’t the best idea.

[00:01:25] Now, this may send alarms off in your head. You may be thinking that this is somewhat

[00:01:30] heretical if you follow this fundamental concept, if you were taught very strongly to never repeat

[00:01:39] yourself. But I encourage you to take a step back and start questioning some of the things

[00:01:45] that you learned early on in your career. There are certain things that you learned

[00:01:50] kind of the practical pieces of, probably, but you didn’t learn them.

[00:01:55] You didn’t learn the whys and also the exceptions to the rule. So the rule here is not to repeat

[00:02:03] yourself, but there are exceptions to almost every rule, especially in programming. And

[00:02:09] let’s talk about a few of those exceptions for the don’t repeat yourself or DRY principle.

[00:02:15] But before we talk about those exceptions, I want to say that especially if you’re a

[00:02:21] young programmer, that the rule don’t repeat yourself, once again, is a very important

[00:02:25] rule.

[00:02:26] This rule is a good guideline. In fact, it is usually applicable. This is one of those

[00:02:31] scenarios where you have to know the rules in order to know when to break them.

[00:02:36] Like many of my episodes, this one gained some inspiration from Sandy Metz. Sandy talks

[00:02:43] a little bit about when you should repeat yourself. Specifically, Sandy talks about

[00:02:49] repeating yourself before you refactor your code. And then once you refactor your code,

[00:02:55] you can remove that repetition. So the whole idea of repeating yourself and when that is a valid

[00:03:02] practice rather than a bad practice is when you’re trying to understand a given method.

[00:03:09] It is much easier for you to repeat yourself in that moment. And it’s very easy to copy and paste

[00:03:15] code. So instead of trying to refactor as you go, it makes much more sense to repeat some of

[00:03:23] the steps that you’ve made, perhaps in another way. So let’s talk about the rule.

[00:03:25] This is really the primary exception to the rule. And that is repeat yourself when you’re

[00:03:33] trying to understand your code. We have this misconception that we understand our code

[00:03:39] as soon as we write it or that we understand our code even before we write it. But it is

[00:03:44] very likely that the only time that you actually understand your code is after you write it

[00:03:50] and after you’ve experienced a bug with the way that you’ve written it. So let’s talk

[00:03:55] for a second about this.

[00:03:55] So let’s talk for a second about the rule.

[00:03:55] about why that would be a problem if you don’t understand your code as you’re writing it.

[00:04:00] Specifically, if code is run twice, then something is duplicated. Now, I’m not saying the code

[00:04:07] specifically has to be duplicated, but that the actual actions that are taking place happen twice.

[00:04:15] So by trying to refactor your code on the spot, by trying to offset that code into a different

[00:04:21] location, what you’re doing is creating an abstraction. And abstractions are only well

[00:04:28] created in the refactoring process. So to summarize this point that Sandy is basically making,

[00:04:35] whenever you are writing code, if one piece of code mimics a lot of the functionality of another

[00:04:42] piece of code, then in the process of writing that method or that data structure or whatever

[00:04:48] it is that you’re writing, it’s perfectly fine for you to do that.

[00:04:51] Duplicate the code that you’ve already written in order to understand step by step what exactly

[00:04:57] is happening. This is especially important if you’re doing something relatively complex

[00:05:02] and also if you’re modifying the way that that code initially was working. So for example,

[00:05:08] you’re adding a step or perhaps you’re changing a variable here or there. This process of seeing

[00:05:15] things in a more granular perspective of actually repeating the code and then taking a step back

[00:05:21] and comparing the two pieces of code, that gives you a perspective on how to create the abstraction

[00:05:28] in a more efficient manner, how to create it in a more effective manner. If you’d like to read up a

[00:05:35] little bit more on what Sandy has to say about this subject, once again, I can recommend to you

[00:05:41] the Practical Object Oriented Design with Ruby and the principles that you learn in Practical

[00:05:49] Object Oriented Design from Sandy.

[00:05:51] It will carry over to pretty much any other language. And in fact, I think that it carries

[00:05:57] over even into functional language programming. Sandy has a background in small talk, but a lot

[00:06:03] of the things that you will learn when you read that book are certainly applicable as overarching

[00:06:09] concepts in other languages as well. Now, while we’re on the subject of learning and reading,

[00:06:14] I want to talk about today’s sponsor, CodeSchool. CodeSchool is full of incredible content

[00:06:21] not only for young developers or people who are beginners, but also for much more experienced

[00:06:27] developers. And that’s because they have just a super wide variety of content. You can learn

[00:06:33] things like Ruby, JavaScript, and HTML, and CSS. But if you already know most of that stuff,

[00:06:38] or if you feel like you don’t need the beginner courses on that, there’s also deeper courses

[00:06:44] in completely different things. For example, if you go to their electives path, they have a regular

[00:06:50] expressions course.

[00:06:51] They have a try R course, the R programming language for statistics. They have a Google

[00:06:58] Drive API course, and they have a Chrome DevTools course. In fact, all four of these courses that I

[00:07:05] mentioned are actually free. So just a ton of content on CodeSchool. A lot of it is free. Go

[00:07:11] and check it out, codeschool.com. Of course, there’s a link in the show notes. And if you use

[00:07:16] that link, CodeSchool will know that you came from developer T. Thanks again to CodeSchool.

[00:07:21] for sponsoring today’s episode. So we’ve been talking about questioning our assumptions and

[00:07:27] specifically about questioning the idea that our code should always be dry. I mentioned that Sandy

[00:07:34] Metz has some interesting things to say about this, specifically Sandy’s position on writing

[00:07:40] your code before you refactor your code, and that making code dry is a part of that refactoring

[00:07:47] process. That when you are writing your code, you don’t really understand it yet.

[00:07:51] And it sometimes takes repetition. Sometimes it takes actually walking through each and every

[00:07:57] step of that process to know how you want that abstraction to look in the end. And maybe you

[00:08:03] never will create that abstraction. Maybe that code will remain repeated. And when is that

[00:08:12] an okay thing? When is it okay to have repeated code? That’s the second exception. The second

[00:08:19] exception is when your code is dry. When your code is dry, when your code is dry, when your code is

[00:08:21] likely to change in the future so that that abstraction makes it harder to change rather

[00:08:29] than easier to change. What is the easy way of saying that? Well, basically, if you think that

[00:08:35] this method isn’t going to be able to cover all of the future flexibility that you need in that

[00:08:41] method, for example, if you think that a particular query or if you think that a particular part of

[00:08:48] that method, a few different steps, are going to change in the future,

[00:08:51] then it makes sense to repeat the code. So this is how that actually plays out

[00:08:56] in a real-life scenario. Let’s say you create a basic function that takes a few arguments

[00:09:02] and returns something that uses those arguments and combines them together.

[00:09:07] Pretty common situation. Now, let’s imagine that you wanted to expand the functionality

[00:09:13] of that particular method to take a third argument and maybe do something slightly different,

[00:09:20] given that the argument is not going to be able to cover all of the future flexibility that you

[00:09:21] need in a different context. Well, now you have to make that method more flexible. Now, if you do

[00:09:27] that enough times, then that method becomes an overly complex, overly flexible, and ultimately

[00:09:35] overly complicated method. And this goes against so many other coding practices. So what you’re

[00:09:43] trying to do by making your code dry, by creating this single method that can take a bunch of

[00:09:49] configuration options and that can take a bunch of configuration options and that can take a bunch of

[00:09:51] arguments to shift the way that that method is called, ultimately, you’re actually making it

[00:09:57] more difficult in the future because what you actually most likely need is either more methods,

[00:10:04] maybe two or three methods that are composed together, or you need to just simply repeat

[00:10:10] yourself, especially if there is a high amount of variability in the different ways that you’re

[00:10:16] calling that method. So if that kind of was a little bit too much for you, then you can just

[00:10:21] repeat yourself. If that kind of was a little bit too difficult to understand, then to put it simply,

[00:10:24] if your methods, if your abstractions become too flexible, then they become overly complex. And

[00:10:30] it’s better for you to repeat code than to create complex code. Well, let me say that one more time

[00:10:37] because it really summarizes what I’m trying to say in this episode as a whole. It is much better

[00:10:43] for you to have repeated code than to have complex code. Now, this may feel a little bit antithetical

[00:10:50] to what you’re saying, but it’s not. It’s not. It’s not. It’s not. It’s not. It’s not. It’s not. It’s not.

[00:10:51] You’ve been taught about maintainability when it comes to code. And that’s because usually less

[00:10:57] code means less complex code. More code typically adds complexity. But when more code, when verbosity

[00:11:06] of your code makes it easier to read and easier to understand and easier to change, then it is

[00:11:13] better than less code. It is better than the dry version of that code. Now, the main argument

[00:11:19] against this is that if you have to change something in more than one place, then that

[00:11:24] makes it difficult. And that’s something that you have to weigh as the developer. Is it easier for me

[00:11:30] to change this thing in two places than to create an overly flexible, overly powerful method that I

[00:11:38] can’t understand in the future? If that is easier, if it is easier for me to change it in two places,

[00:11:44] then dry may not be the most helpful principle in that particular scenario.

[00:11:50] It’s crazy to think that some of the things that we’ve been taught, or perhaps some of the things

[00:11:54] that we read on a daily basis about programming, some of them may need more context to really make

[00:12:01] sense each and every day in what we do. But I would like to challenge you to question everything,

[00:12:08] question everything that you learn, and try to investigate why and where those principles

[00:12:14] actually apply. Investigate the things that you hear on this podcast,

[00:12:19] and determine how they fit into the work that you are doing each and every day. I’d love to hear

[00:12:25] about the things that you are questioning about what you’ve learned, about programming practices,

[00:12:31] or even completely unrelated stuff about life or about relationships. All of these things play into

[00:12:38] the work that we do as developers. You can reach out to me on Twitter at developer T,

[00:12:44] or you can email me at developer T at gmail.com. I’d like to once again,

[00:12:49] thank you so much for joining me today. I’ll see you next time.

[00:12:49] Today’s sponsor, CodeSchool. Go to codeschool.com. If you are looking to learn how to code,

[00:12:54] or if you’re looking to expand your existing knowledge with new electives on things like

[00:13:00] regular expressions, or the Google Drive API, or if you want to learn R, go and check it out,

[00:13:07] codeschool.com. Of course, there is a link in the show notes for that as well. Thank you again for

[00:13:13] listening to today’s episode. Of course, developer T is a part of the spec network. That’s spec.fm.

[00:13:19] Go and check it out. There’s other shows and interesting resources always being added to

[00:13:24] spec.fm. Thank you so much for listening to today’s episode. Until next time, enjoy your tea.

Visão de gráfico