In today's episode I'll dig into mutable states and go over two things you can do to get away from relying on states. Today's episode is powered by Code School. Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. Visit www.CodeSchool.com/developertea for more information and start playing courses now.
In today's episode I'll dig into mutable states and go over two things you can do to get away from relying on external states so you can read and test methods. Be sure to check out Sandy Metz's 2015 Railconf talk "nothing is something" on why conditional statements make code more difficult to reason.
Special thanks to Today's sponsor: Code School
Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. Visit www.CodeSchool.com/developertea for more information and start playing courses now.
Thanks for listening and until next time,
Enjoy your Tea
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. 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. First I want to talk a little bit about some of the problems that this idea is going to solve. Have you ever spent time in a room and you were like, I don't know what to do. You're writing your code, trying to figure out, trying to walk through each step and figure out what exactly is happening at a given step. Now 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. In fact, you are simply writing the code that explains what you're doing. So what do you want the computer to do? Functional programming languages try to fix this problem by eliminating the idea of mutable state. The word mutable means that the state can change. Now imagine that you have, for example, a class level variable. And that class level variable determines how a particular function runs. Maybe you have an if statement in that function that checks that class variable. At the same time, you may have an evolution variable that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. At the same time, you may have evolution variables that may have evolution variables. that method, then when you're reading that, you have to consider those things without actually seeing them. In other words, the state is difficult to determine, and the outcome of running a particular method becomes even more difficult to determine. 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. There are ways to subvert the hard parts in this problem. Have you ever found yourself writing a test that sets up a scenario? 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, 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 statement. Just to check a single method. Now let me be clear, sometimes integration tests exactly like this are important, and you should be creating those for the most critical paths in your application. 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. In a minute, we're going to discuss two things that you can do to make your code more organized. First, you can do a test to make your code a little bit easier to reason about, and to get you away from relying on state, 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. Thanks so much to today's sponsor, CodeSchool. CodeSchool is an online learning destination for existing, and aspiring developers that teaches through entertaining content. By pairing immersive video lessons with in-browser challenges, CodeSchool has become the best place to learn new technologies from the comfort of your browser. Each course features a unique theme and storyline, so you feel like you're playing a game rather than sitting in a classroom. Whether you've been programming for decades or have only just begun, CodeSchool offers something for everyone. Choose your learning experience from CodeSchool's five main paths, JavaScript, Ruby, Git, and HTML and CSS, or iOS. Or you can take advantage of CodeSchool's growing number of elective courses like Tri-R and Chrome DevTools. Take your learning on the go directly from your iPhone or iPad from the free CodeSchool iOS app. More than a million people around the world use CodeSchool to improve their development skills and learn by doing. You can join them by visiting codeschool.com slash developer T for more information and to start playing courses today. So we've been talking about mutable state and trying to get away from relying on mutable state to determine how a given method will run. 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. This first, I've got a couple of methods that I've used to write code. I've used the code to write code forension and evolution. At the very least, they may have taken the evolution my conversation with Chris Keithley. Chris was talking to me about arranging data and performing different queries through REST type interfaces. And he mentioned that people have a hard time separating the arrangement of their code from the actions of their code. So this is my first tip for you today. Create the arrangement parts of your code and quarantine them away from the action parts of your code. So in practice, this, for example, might look like you defining all of your variables and all of the pieces and parts that you're getting ready to use first. So avoid defining those variables interspersed with the actions that you're taking throughout the rest of the method. Another thing I've been practicing recently is substituting methods for queries. So instead of actually writing the query out inside of my method, I will offset that into another method. This allows the query to be easily reusable and it completely quarantines the arrangement, which in this case is the query, away from whatever actions you want to take on whatever that data is, whatever that query returns. Now the second idea is, to simply reduce the number of times that you use conditional statements. Now this is the hardest challenge of the two because it requires you to think in a new way. The truth of the matter is, when you introduce a conditional into a method, that method is basically split into two different branches of a method, one running if that conditional passes and one running if it doesn't. But if you begin to add nested conditions, you're going to have to think in a new way. So if you start adding a number of conditionals, then you start creating a very complex situation where there are basically multiple methods nested inside of a singular method. As a rule, I like to keep my conditional statements to a minimum, hopefully nested at most two conditionals, preferably only one conditional in a given method. Now there's a lot of techniques that will help you reduce the number of conditionals in your code. The first one is the number of conditionals in your code. The scope of this episode is too small to cover them all, but for a good primer on this subject, I would recommend you check out Sandy Metz's talk from 2015 RailsConf, Nothing is Something. In this talk, she'll give you a little bit more intuition as to why conditional statements make code a little bit more difficult to reason about and how to avoid those conditional statements. Sandy specifically talks about how to deal with when an object is a conditional. She brings up the evolution ofension and evolution of evolution, bringing evolution to evolution, In Ruby, we call this nil. In JavaScript, this is null or perhaps undefined. But we experience this situation in pretty much every programming environment. The idea that a given reference is empty and how to deal with it. Go and check that talk out. It will be in the show notes. So I challenge you to these two things. Number one, start building your code so that the arrangement part of your code is quarantined away from the action part of your code. And secondly, reduce the number of conditional statements, the ifs and the switches and the cases. Reduce the number of those statements and instead focus on doing one thing at a time and doing it explicitly. I can almost guarantee that your code is gonna be easier to read. Other people will find your code much easier to reason about and much easier to work on after you have finished working on it. Your tests are gonna be much easier to write. You'll become a much better programmer and therefore you'll be happier. Now I know this sounds very big. I know this sounds lofty and the goals seem really high. But the reality is these simple changes, these are the things that make your job easier, that make each and every day, the moments of your life less frustrating, a little bit more zen-like if you wanna use that term, a little bit easier to deal with, and you can get through it. And I think that's the hard part. So I hope you enjoyed this episode of Developer Tea. I've got one more thing to talk about, and that is learning. You guys know that it's so important to keep on learning as a developer each and every day. I've done so many episodes on how to become a better learner, but perhaps the best way to be a better learner and the best way to learn is to do, to actually get on the ground and start coding. And Code School, is a way that you can start doing that. Code School is today's sponsor, of course. You can go and check it out at codeschool.com slash developer tea. That's a special link that lets them know that you're coming from Developer Tea. I would really appreciate if you use that link, which is in the show notes. But Code School is a great option for you, whether you are at the beginning of your career, just learning how to do the very first basic hello world stuff, or if you're well into your career and you wanna learn more about a given subject, they've got a lot of great stuff. They've got a lot of great stuff. They've got a lot of great stuff. They've got so many different courses. They've even got electives. So go check it out, codeschool.com slash developer tea. Thank you again for listening to today's episode. And until next time, enjoy your tea.