Ruby
Using Pokemon To Catch All Code Smells
Summarized using AI
Using Pokemon To Catch All Code Smells
by Melanie KeatleyIn her talk at Euruko 2019, Melanie Keatley presents a unique approach to understanding code smells through the lens of Pokémon, making the concept more relatable and easier to comprehend. Keatley, who transitioned from journalism to software development, initially faced imposter syndrome but found confidence through learning about code smells—a term for poor practices in code that can lead to problems. The main points discussed include:
- Personal Background: Keatley shares her journey from journalism to software development, emphasizing the importance of self-acceptance and learning.
- Code Smells: She introduces the term 'code smells' and explains its significance in writing maintainable code.
- Pokémon Analogy: Drawing parallels between Pokémon types and code smells, Keatley proposes creating characters for various code smells to better understand them. For example:
- ChatScula represents excessive comments in the code.
- Speculative Generality embodies unnecessary future-proofing of code.
- Divergent Change, illustrated by Dominiontron, makes changes to a class more complicated.
- Groups of Code Smells: Keatley categorizes code smells into groups, such as 'Dispensables' (easily removable code), 'Change Preventers' (hurdles to making changes), and 'Bloaters' (unnecessarily large code structures).
- Benefits of Doodling: She also discusses research suggesting that doodling, like creating Pokémon characters for code smells, can significantly improve memory recall and creativity, as visuals aid in information processing.
- Actionable Takeaways: Keatley encourages engineers to engage in visual learning techniques, hinting at the underutilization of doodling in programming discussions. She urges teams to incorporate more visual methods into their workflows for better understanding and communication.
In conclusion, Keatley's presentation creatively bridges a childhood favorite with the technical world, allowing developers to tackle code smells more effectively and enjoyably. The session reveals that drawing or doodling can not only aid in memory retention but also foster collaboration and innovation in coding practices.
00:00:06.319
So, next up is Melanie. Melanie is over here, and she likes to call bugs 'surprises'. She sells yarn on Etsy. Actually, actual yarn! I still think it makes you JavaScript though. So she's going to tell us a little bit today about using Pokémon to catch code smells. You can guess what my favorite type of Pokémon is: water. And with that, I'll leave you to it. By the way, she told me yesterday that she had this talk for all her colleagues, and I was very nervous for that, but she was not at all nervous for today. So I think that this is definitely worse. Please, I was so jealous! So please join us in giving Melanie a warm welcome.
00:01:11.040
Good morning, everybody! It's still almost afternoon, almost lunchtime, but it doesn't matter if I talk fast because lunch is not going to be ready until it's ready. Oh well! My name is Melanie Keatley, and I work at Young Capital. We are the fastest-growing employment company in the Netherlands. It's funny, actually, because the second talk we had today was about job boards and it was very recognizable for many of us on the team since we have so many job boards. We also deal with things like contracting and declarations of hours, and there's lots of magic involved in employing people.
00:01:21.200
This is a picture from one of our most recent hackathons where we were doing gamification. My team was hooking up a Dance Dance Revolution mat to a Raspberry Pi for reasons. It's a really great team; I’m sure everybody loves their teams, but I really love mine. And there are lots of Young Capital people walking around in black t-shirts, so come talk to us—we're a fun bunch!
I studied journalism in college, which means I'm kind of good at Googling stuff, and that's really useful in software development. However, I am also a raging introvert, so I quickly discovered that journalism wasn't really for me, and I switched to communications. I worked in that area for a little bit, and when I was 33, I was filling lots of websites with content and writing newsletters, but I really wanted to create those websites. So, I signed up for a Rails Girls workshop in October 2013, similar to the one that was organized yesterday, and I just loved it so much. It felt like I was opening the hood of a car— I can do all this stuff, this is amazing!
00:01:55.680
I almost didn't make it to that workshop because a week earlier, I tried to teach myself how to skateboard and ended up in the ER. This is me and my sister in the back; she's got my skateboard on her lap. But for some reason, I decided to drag my broken foot and crutches on a train from Amsterdam to The Hague, and I got to the workshop. It was amazing! Six years later, I’m on the Euruko stage, so hooray for doing things!
So, I'm not here to talk about my feet today. I'm here to talk about brains. My brain can be super annoying; it sometimes tells me, 'you don't belong here.' Some people might call this imposter syndrome or anxiety. Imposter syndrome is the internalized fear of being exposed as a fraud. For me, it's a feeling that everybody else is just way better at this than I am. This didn't magically appear when I started doing software development; I had it in communications and even in college. As a parent, I feel it too, as if all the other moms know what they're doing and I'm just faking it.
00:03:12.680
Earlier this year, something funny happened—I had a really good annual review at work. People were saying nice things about me, and it felt like a smack in the face. I thought, 'Damn, these people take me seriously! I need to start taking myself seriously, and my career seriously.' So, I decided to take this sort of path towards self-acceptance and showing up for myself. I thought, 'Let’s start with the basics and learn about code smells.'
It turns out there’s nothing like learning to shut up your stupid brain. To learn about code smells, I went to YouTube because it’s 2019. I watched a talk by Sandy Metz called 'Get a Whiff of This,' which is for RailsConf, and I really recommend watching it if you haven't seen it already. In that talk, a book by Martin Fowler and Kent Beck is heavily referenced—it's called 'Refactoring.' I don’t know if you've seen it; it’s really big, very thick, lots of pages, lots of words.
00:04:12.640
To make it easier, there's a company called Industrial Logic which made this PDF—a kind of cheat sheet called a reference guide to code smells. On the left, we have code smells, and on the right, it references where in the book you can find a way to defeat this code smell. As I looked at this page, I thought, 'This looks like the strategy guide I used to play Pokémon as a kid.' You can find these strategy guides online now, but back in the day, my sister and I would go to a physical store, buy gaming magazines where we would have these strategy guides that said, for instance, 'A rock Pokémon is weak against water, and fire Pokémon are great against bug types and grass types.'
This sparked an idea in my brain: Pokémon are super similar to code smells— they belong to a certain group, have a particular way of being defeated, and they all have really silly names. Why don't I create a Pokémon for each code smell?
00:05:30.560
So, okay, cool, what do Pokémon look like? On one hand, we have Ditto, and I can do this, I think. But we also have Charizard, and I'm not an artist; I can't draw that— it's hard for me. So, I thought, 'The idea of this exercise is not for me to become a super fancy artist; I’m going to pull out the essence of what a code smell is and create a super simple character—something that works for my brain—and then just give it a weird name.' And that’s what I did! This is my notebook where I drew little characters.
00:06:36.000
Let’s go through them! The first group is 'Dispensables,' which are things in your code that you can easily get rid of. The first one is ChatScula, who represents comments. His mouth is a little hashtag. This also brings me to a point about code smells: code smells are not inherently terrible and should never be done. It's just that if you have a ton of comments to make your code understandable, then maybe there's some refactoring in order. It’s a smell; it’s not that it’s bad, but it might be something to look at.
The next group is the 'Data Class Container.' This is a class that only holds data; other objects in your code use all that data, but the class itself has no functionality. Duplicate code, or copy-paste coding, is another common issue. People say, 'Ah, duplicate code is terrible, and I never do that!' But it happens quite frequently. We all understand this, right? You're doing Agile; you get a ticket that says to do the thing. You do the thing. Do you check your entire code base for duplication? Probably not.
00:07:40.639
Next is Lazy Class, which represents a giant codebase that takes time from your team and is expensive to maintain. If you have classes that do not earn their keep, you should try to get rid of them. The same goes for dead code—if it’s not doing anything, get rid of it. This brings me to one of my characters: Speculative Generality. He has little question marks for eyes because this is where you build something and think, 'Maybe later, I can use this parameter.' Don’t build it now if you don't need it.
The next group is 'Change Preventers.' This group includes things that are in your code that make it hard to change, or you get fearful of changing. For instance, there’s Divergent Change, which I call Dominiontron. Suppose you have a class, say a Product class, and you're adding types; now you have to change the methods for finding, displaying, and ordering products.
00:08:38.320
The next group is Shotgun Surgery, which is when you know you're in 'shotgun surgery hell.' You make a tiny change and then have to make all these other tiny changes throughout your codebase. I really like drawing this one because it looks like a gun shooting hearts and health since it’s trying to make everything better. Next is Iceberg, representing Parallel Inheritance Hierarchies. Here, you have a parent class and a subclass. You make changes to the subclass, and then you have to make changes to all the other subclasses, leading to what I call the 'Bloaters.'
The Bloaters are things that plump up your code, like LongTrum, who represents the long method, and Largoth, who represents large classes, along with Silla, the long parameter list. Then there’s Clumping Data Clumps. Data Clumps occur when you have groups of parameters throughout your code that are the same, appearing over and over. You can extract those and put them in a separate class to make your code modular.
00:09:50.000
Prometrion represents Primitive Obsession; this is when you're using primitives instead of small objects. This situation leads you to ask yourself, 'Do I need to write an entire class for this, or should I just use a string?' It’s not the right tool for the right job—it feels like fitting a square peg into a round hole. Next, we have Couplers, with Fency for Feature Envy. This is when a method accesses data from another object way more than its own data, reminiscent of a little guy always looking over the fence at greener grass on the other side. I gave him a fishing hat as a fun addition.
Grabite represents Inappropriate Intimacy; this happens when your class uses the internal fields of other classes. Chainron is for Message Chain; your code is structured as a series of message calls. This reminds me of that game kids play, Chinese whispers, where someone whispers something in one kid's ear, and it changes as it goes down the line.
00:10:44.400
Middleman or Middle Manager represents one who just tells everybody else what to do, leading you to wonder, 'Why does he exist?' This is the last group: Abusers, which includes incomplete or incorrect applications of object-oriented programming principles. This is represented by Switchzilla, the complicated switch statement, and Temptii, who is the temporary field. Is there a value in this field or not? It's really hard to tell. If your code is hard to understand, it’s expensive because people keep looking at it over and over again, wasting time and hence wasting money.
This is my absolute favorite—every parent will understand this situation; I call this one Refusion, which stands for Refused Bequest. This occurs when you have a parent class and a child class where the child class uses some methods and properties from the parent class, but not everything. This reminds me of my four-year-old, who is super happy to eat white rice all day long, but if I give him vegetables, he's like, 'No, I don’t want that!'
00:12:12.240
The last one is SameClops—alternative classes with different interfaces. These two classes perform identical functions but have different method names, reminding me of two cans of cola: Pepsi and Coke. So, this is why I drew them like this. So, it’s a little bit silly, right? Drawing Pokémon for code smells is a fun exercise but it really helped me understand and retain this information.
00:13:31.600
I wanted to learn more about this. Why does doodling silly characters work? As someone who was formerly a journalist, I did some research—I went to Google. In 2016, the University of Waterloo in Canada did a series of experiments on memory recall. They divided people into groups: Group A was instructed to engage in rote learning, which is writing a word repeatedly to try and stick it in your brain. The second group was instructed to draw a picture, like an apple or balloon. After a bogus exercise, they quizzed them on how many words they could recall in 60 seconds. It turned out that the doodlers remembered twice as many words as those who engaged in rote learning.
00:14:41.440
Scientists speculate that picture memory is superior because pictures create an automatic connection to the images in your brain. For example, if you draw a tree, your brain connects it to the tens of thousands of pictures of trees you've seen in your lifetime. The word 'tree' is just that—lower! Great news for people like me who aren't amazing artists: the quality of the picture does not reflect the ability to recall. You can make whatever works for you, and that’s fine.
Doodling has benefits beyond memory recall; the rhythmic motion of doodling activates a relaxation response in your body, countering fight-or-flight instincts and reducing cortisol, which is the body's stress hormone. We’re very visual creatures; a study from Drexel University showed that making art stimulates the brain's reward center. Participants also reported feeling more creative and better able to problem-solve.
00:16:47.840
Generally speaking, humans are better at processing visual data than text; we can process images 60,000 times faster than text. Ninety percent of the information that enters our brain is visual information! Cool, right? But at work, what are we looking at all day? It's words! I'm not saying we should all burn our text editors and start using Scratch and other visual programming tools. While that would be super cool, I don’t think it would be practical.
00:19:30.720
However, we can use this knowledge! If you're trying to grasp a complex programming principle, you can doodle it out. For example, this is the law of Demeter: you can pick your nose, you can pick your friends, but you cannot pick your friend's nose. Are you explaining code smells to fellow engineers? Make Pokémon for them! Explaining something to your project manager? Just get a paper and draw it out for them; sketch it out, give it to your stakeholders, and ask if it will work for them because this is what we’re going to build.
00:21:00.000
Engineering teams should have whiteboard markers coming out of their ears! But do we have that? We are glued to our text editors, and I think we can do better. So, next time you’re at work, pick up a pen and doodle it out. Thank you!
00:21:27.919
Nice! Yes, I really like your visual explanation of the law of demeter.
Explore all talks recorded at EuRuKo 2019
+8