Vox

Leitura de 14 min

Mutable States, Refactory Tips & Reasonable Code Techniques

Summary

In this episode of Developer Tea, host Jonathan Cottrell explores the challenges of reasoning about code that relies heavily on mutable state. He explains how mutable state—where variables can change and affect method behavior—makes code difficult to understand and test, especially in object-oriented design. This often leads to complex test setups just to verify a single method’s functionality.

Cottrell introduces two key refactoring techniques to address these issues. The first technique, inspired by his friend Chris Keithley, involves separating the “arrangement” parts of code (like variable definitions and queries) from the “action” parts. By quarantining arrangement logic, methods become more focused and easier to reason about, as seen in practices like extracting queries into separate methods.

The second technique focuses on reducing the use of conditional statements (ifs, switches, cases). Cottrell argues that conditionals effectively split a method into multiple branches, increasing complexity, especially with nesting. He recommends limiting conditionals per method and suggests watching Sandy Metz’s RailsConf talk “Nothing is Something” for deeper insights into handling null values without conditionals.

By applying these techniques—separating arrangement from action and minimizing conditionals—developers can write more readable, testable, and maintainable code. Cottrell emphasizes that these changes lead to less frustration, easier collaboration, and overall better programming practices, making daily development work more zen-like and efficient.

Recommendations

Platforms

  • CodeSchool — An online learning platform for developers that offers immersive video lessons and in-browser challenges across paths like JavaScript, Ruby, Git, HTML/CSS, and iOS, with a free iOS app for mobile learning.

Talks

  • Nothing is Something by Sandy Metz — A talk from RailsConf 2015 that provides intuition on why conditional statements make code harder to reason about and offers techniques to avoid them, particularly for handling null or empty references.

Topic Timeline

  • 00:00:00 — Introduction to organizing code for better reasoning — Jonathan Cottrell introduces the episode’s focus on organizing code to make it easier to reason about. He mentions that the idea came from his friend Chris Keithley during a Ruby meetup in Chattanooga. The goal is to address common problems developers face when trying to understand complex code.
  • 00:00:43 — The problem of mutable state in code — Cottrell discusses the difficulty of keeping track of mutable state in code, where variables can change and affect method behavior. He explains that this is a key challenge in object-oriented design, as it forces developers to hold multiple pieces of information in their head. Functional programming languages attempt to solve this by eliminating mutable state altogether.
  • 00:02:45 — Testing challenges due to state reliance — The host describes how reliance on mutable state complicates testing, often requiring extensive setup (like creating users, signing them in, and filling forms) just to test a single method. While integration tests are important for critical paths, excessive setup may indicate poor code organization. This leads to the need for techniques to reduce state dependence.
  • 00:05:14 — First refactoring tip: Separate arrangement from action — Cottrell presents the first refactoring tip: quarantine the arrangement parts of code (e.g., variable definitions, queries) away from the action parts. This means defining all variables and setup logic first, rather than interspersing them with actions. He gives an example of extracting queries into separate methods to improve readability and isolation.
  • 00:07:06 — Second refactoring tip: Reduce conditional statements — The second tip is to minimize the use of conditional statements (ifs, switches), as they split methods into multiple branches and increase complexity. Cottrell recommends keeping conditionals to a minimum, ideally one per method, and avoiding nesting. He references Sandy Metz’s talk “Nothing is Something” for strategies to handle null values without conditionals.
  • 00:08:52 — Challenge and benefits of applying these techniques — Cottrell challenges listeners to apply both techniques: separating arrangement from action and reducing conditionals. He explains that doing so will make code easier to read, test, and maintain, leading to less frustration and more zen-like development. The episode concludes with a reminder of the importance of continuous learning through platforms like CodeSchool.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I’m going to be talking to you about a way of organizing each and every piece of code that you have in such a way that makes it easier to reason about.

[00:00:15] This simple idea was introduced to me by a friend of mine here in Chattanooga. His name is Chris Keithley. We were hanging out at a Rupi meetup here in Chattanooga that I organized and Chris introduced me to this idea and I think it’s really useful. I think it’s going to be valuable to you.

[00:00:37] First I want to talk a little bit about some of the problems that this idea is going to solve.

[00:00:43] Have you ever spent time in a room and you were like, I’m going to do this.

[00:00:45] Have you ever spent time in a room and you were like, I’m going to do this.

[00:00:45] Have you ever spent time in your code trying to figure out, trying to walk through each step and figure out what exactly is happening at a given step.

[00:00:55] I’m sure this is applicable in many different situations, but trying to keep information in your mind about exactly what things are happening at that given point in time, that’s a little bit hard to do because you are not the computer.

[00:01:10] In fact, you are simply writing the code that explains what you’re doing.

[00:01:15] In fact, you are simply writing the code that explains what you’re doing.

[00:01:16] Functional programming languages try to fix this problem by eliminating the idea of mutable state.

[00:01:25] The word mutable means that the state can change.

[00:01:30] Now imagine that you have, for example, a class level variable and that class level variable determines how a particular function runs.

[00:01:40] Maybe you have an if statement in that function that checks that class variable.

[00:01:45] Maybe you have an if statement in that function that checks that class variable.

[00:02:15] You have to consider those things without actually seeing them.

[00:02:20] In other words, the state is difficult to determine and the outcome of running a particular method becomes even more difficult to determine.

[00:02:30] This is perhaps one of the hardest parts of object-oriented design and it’s one of the things that you have to be aware of and there are ways around this problem.

[00:02:41] There are ways to subvert the hard parts in this problem.

[00:02:45] Have you ever found yourself writing a test that sets up a scenario?

[00:02:50] For example, creating a user and signing that user in and then visiting a page, maybe using something like Capybara if you’re using Rails.

[00:03:01] And you sign that person in, you visit a page, you fill out a form, and then you do all of these things to set up the state just to check a single method.

[00:03:12] Now let me be clear.

[00:03:13] Sometimes integration tests, exactly.

[00:03:15] Like this, are important and you should be creating those for the most critical paths in your application.

[00:03:23] But if you have to write a test, if you have to set up state in order to check a method, then there could be something wrong with the way your code is organized.

[00:03:34] In a minute, we’re going to discuss two things that you can do to make your code a little bit easier to reason about and to get you away from relying on state.

[00:03:43] To get you away from this.

[00:03:45] To get you away from holding everything in your head so that when you read your methods and when you are testing your methods, you don’t rely so much on the external state and instead you rely on what exactly is happening in that method.

[00:04:02] Thanks so much to today’s sponsor, CodeSchool.

[00:04:05] CodeSchool is an online learning destination for existing and aspiring developers that teaches through entertaining content.

[00:04:11] By pairing immersive video lessons with in-browser challenges,

[00:04:14] CodeSchool has become the best place to learn new technologies from the comfort of your browser.

[00:04:19] Each course features a unique theme and storyline, so you feel like you’re playing a game rather than sitting in a classroom.

[00:04:26] Whether you’ve been programming for decades or have only just begun, CodeSchool offers something for everyone.

[00:04:32] Choose your learning experience from CodeSchool’s five main paths.

[00:04:35] JavaScript, Ruby, Git, HTML and CSS, or iOS.

[00:04:40] Or you can take advantage of CodeSchool’s growing number of elective courses.

[00:04:44] For example, you can take advantage of CodeSchool’s free code school app called CodeSchool iOS, where you can learn how to use CodeSchool to improve your development skills and learn by doing.

[00:04:47] Take your learning on the go directly from your iPhone or iPad from the free CodeSchool iOS app.

[00:04:54] More than a million people around the world use CodeSchool to improve their development skills and learn by doing.

[00:05:00] You can join them by visiting CodeSchool.com slash developer T for more information and to start playing courses today.

[00:05:10] So we’ve been talking about mutable state and trying to get away from reliance on code.

[00:05:14] Relying on mutable state to determine how a given method will run.

[00:05:19] I want to give you two basic refactoring tips, two basic ways of looking at your code from here on out that will help you write methods in such a way that they don’t rely as much on state, that the state is a little bit easier to reason about.

[00:05:36] This first idea comes directly from my conversation with Chris Keithley.

[00:05:40] Chris was talking to me about arranging data.

[00:05:44] And performing different queries through REST type interfaces.

[00:05:49] And he mentioned that people have a hard time separating the arrangement of their code from the actions of their code.

[00:05:59] So this is my first tip for you today.

[00:06:01] Create the arrangement parts of your code and quarantine them away from the action parts of your code.

[00:06:10] So in practice, this, for example, might look like you defined.

[00:06:14] Defining all of your variables and all of the pieces and parts that you’re getting ready to use first.

[00:06:21] So avoid defining those variables interspersed with the actions that you’re taking throughout the rest of the method.

[00:06:29] Another thing I’ve been practicing recently is substituting methods for queries.

[00:06:34] So instead of actually writing the query out inside of my method, I will offset that into another method.

[00:06:42] This allows the query to be easily readable.

[00:06:44] And it completely quarantines the arrangement, which in this case is the query,

[00:06:51] away from whatever actions you want to take on whatever that data is, whatever that query returns.

[00:06:58] Now the second idea is to simply reduce the number of times that you use conditional statements.

[00:07:06] Now this is the hardest challenge of the two because it requires you to think in a new way.

[00:07:11] The truth of the matter is,

[00:07:13] when you introduce a conditional into a method,

[00:07:17] that method is basically split into two different branches of a method.

[00:07:22] One running if that conditional passes and one running if it doesn’t.

[00:07:27] But if you begin to add nested conditionals,

[00:07:31] then you start creating a very complex situation

[00:07:35] where there are basically multiple methods nested inside of a singular method.

[00:07:41] As a rule,

[00:07:43] I like to keep my conditional statements to a minimum,

[00:07:46] hopefully nested at most two conditionals,

[00:07:50] preferably only one conditional in a given method.

[00:07:54] Now there’s a lot of techniques that will help you reduce the number of conditionals in your code.

[00:08:00] The scope of this episode is too small to cover them all,

[00:08:03] but for a good primer on this subject,

[00:08:05] I would recommend you check out Sandy Metz’s talk from 2015 RailsConf,

[00:08:11] Nothing is Something.

[00:08:13] In this talk, she’ll give you a little bit more intuition

[00:08:17] as to why conditional statements make code a little bit more difficult to reason about

[00:08:22] and how to avoid those conditional statements.

[00:08:25] Sandy specifically talks about how to deal with when an object is simply not present.

[00:08:32] In Ruby, we call this nil.

[00:08:34] In JavaScript, this is null or perhaps undefined.

[00:08:38] But we experience this situation in pretty much every programming environment.

[00:08:42] The idea that a given reference is empty and how to deal with it.

[00:08:47] Go and check that talk out.

[00:08:49] It will be in the show notes.

[00:08:50] So I challenge you to these two things.

[00:08:52] Number one, start building your code so that the arrangement part of your code

[00:08:58] is quarantined away from the action part of your code.

[00:09:02] And secondly, reduce the number of conditional statements,

[00:09:06] the ifs and the switches and the cases,

[00:09:10] reduce the number of those statements,

[00:09:12] and instead focus on doing one thing at a time and doing it explicitly.

[00:09:18] I can almost guarantee that your code is going to be easier to read.

[00:09:22] Other people will find your code much easier to reason about

[00:09:26] and much easier to work on after you have finished working on it.

[00:09:30] Your tests are going to be much easier to write.

[00:09:33] You’ll become a much better programmer and therefore you’ll be happier.

[00:09:37] Now I know this sounds very big.

[00:09:39] I know this sounds lofty.

[00:09:41] And the goal is to be able to write.

[00:09:42] The goals seem really high.

[00:09:43] But the reality is these simple changes,

[00:09:45] these are the things that make your job easier,

[00:09:48] that make each and every day,

[00:09:50] the moments of your life less frustrating,

[00:09:52] a little bit more Zen-like,

[00:09:54] if you want to use that term,

[00:09:55] a little bit easier to deal with the hard parts.

[00:10:00] Thanks so much for listening to today’s episode of Developer Tea.

[00:10:04] I’ve got one more thing to talk about,

[00:10:06] and that is learning.

[00:10:07] You guys know that it’s so important to keep on learning as a developer each and every day.

[00:10:12] I’ve done so many episodes on how to become a better learner.

[00:10:16] But perhaps the best way to be a better learner and the best way to learn is to do,

[00:10:23] to actually get on the ground and start coding.

[00:10:26] And Code School is a way that you can start doing that.

[00:10:29] Code School is today’s sponsor, of course.

[00:10:31] You can go and check it out at codeschool.com slash developer tea.

[00:10:35] That’s a special link that lets them know that you’re coming from Developer Tea.

[00:10:39] I would really appreciate if you use that link.

[00:10:41] Uh, which is in the show notes,

[00:10:43] but Code School is a great option for you,

[00:10:46] whether you are at the beginning of your career,

[00:10:48] just learning how to do the very first basic hello world stuff,

[00:10:52] or if you’re well into your career and you want to learn more about a given subject,

[00:10:56] they’ve got so many different courses.

[00:10:58] They’ve even got electives.

[00:10:59] So go check it out,

[00:11:00] codeschool.com slash developer tea.

[00:11:03] Thank you again for listening to today’s episode and until next time,

[00:11:06] enjoy your tea.

[00:11:11] .

Visão de gráfico