1. Renée De Voursney July 14, 2011 ConferenciaRails How I learned to smell code Photo credit: http://www.vlib.us/medical/gaswar/Exp.%20Dog%20Mask,%20WWI.jpg
2. How many of you went to university for Computer Science? How many have a background in business consulting or working in the Microsoft stack (C#)? I will assume we all currently work with Rails. How many have a main app that is Rails <= 2.0.5? Rails 2.3.x? Rails >= 3.0.x? Who is out there? Photo credit: http://www.flickr.com/photos/drachmann/327122302/sizes/l/in/photostream/
9. Strives to live up to the principles learned onRenee’s Road to Scentless Code
10. A hound surrounded by wonderful smelling flowers, is to a developer working with: Well documented code A working application Well designed and maintainable code What I want Photo credit: http://timesnow.info/Download/images/pet_animals/cute_puppies/spring_scents_basset_hound.jpg
11. Writing and then Maintaining Lots and Lots of stinky code! How did I get there? Renee’s Road to Scentless Code Photo credit: http://static.howstuffworks.com/gif/pug.jpg
14. Teaching someone else is the best way to learn and re-enforce your understanding of a concept
15. Objects, javadoc, and the JVM are really cool! What Did I learn Photo credit: http://www.mentalfloss.com/wp-content/uploads/2007/10/tongue_stuck_on_pole.jpg
25. Always leave things greener than you found them.Photo credit: http://ihasahotdog.files.wordpress.com/2008/09/funny-dog-pictures-dog-blames-a-bad-smell-on-the-baby.jpg
26. Where am I now I’ve learned Ruby I’ve learned Rails I’ve worked with lots of legacy RoR code I’ve written both really bad and really good RoR code
28. Participate in the awesome program! Teach people Rails! YOU will learn something! New Programmers can learn good patterns and practices for scentless code by following Rails Patterns. Rails has excellent patterns for Beginners to follow (RESTful). Suggestion 1:
29. You have been doing the same thing too long. You don’t practice enough. Change your perspective, try it another way, NEVER STOP LEARNING TO CODE! Suggestion 2:
33. Let other’s make mistakes and learn Never be afraid to try something, even if it might be smelly Always be willing to change your code! Replace comments with method calls Renee’s Road to Scentless Code Photo credit: http://timesnow.info/Download/images/pet_animals/cute_puppies/spring_scents_basset_hound.jpg
34.
35. Clean Code – Robert C. Martin – 2009 Pearson Education Inc.
36. The Pragmatic Programmer – Andrew Hunt, Dave Thomas – 2000 Addison-WesleyReferences Renée De Voursney Twitter: @gigglegirl4e Email: renee.devoursney@gmail.com Special Thanks to Wayne Seguin and Sandi Metz for helping prepare and inspire this talk.
Notes de l'éditeur
Hola, thank you for having me here today! I’m going to be telling you a story, my story. I hope you get something out of it, and if not I hope it amuses you.Before I tell you about myself, I’m going to ask you some questions. I know! Audience participation at a software conference, how awful of me! And just before lunch too! Don’t worry they are not questions about food!Also, everyone has heard the term “code smell before right?”
Just for fun, how many of you are rock climbers?
Like Rails! Especially ones that follow or teach us maintainable patterns and practices of ways to structure code.
What is at the end of the Road? What’s the light at the end of the tunnel?I love descriptive analogies, especially ones that come with a picture of a dog!So which is it? I think I made this pretty obvious, but just in case.
What is this? This is my story.I’m going to be telling you about my experiences with code, the Good, the Bad ,and the Goofy!This explains my questions. I was wondering who out there has a similar background to mine. I went to university for computer science, I worked as a business consultant doing custom development in the Microsoft stack, and now I work as the lead Ruby developer for Blue Box Group.I’ve worked with lots and lots of code of different varieties, and each of the three different places where I have written and had to maintained code I’ve learned something different about what makes for good code and what makes for bad code.Using my hound sniffing analogy, you can say my code sniffing ability grew with each step of my journey.
At university I did a lot of java and C programmingThough we were using java to learn about objects, most of the code I wrote and learned from was procedural in nature and had lots of conditionals:A situation I like to refer to as if-else-death.Working with teams was vile,Tests were unheard ofAnd I rarely every looked at code that was quote ”finished” – ie: code for a completed assignment (in fact I had trouble finding code from that time to make this awful picture of java code for this talk)So with my dog analogy: a dog with a refined sniffer at this point would look at my code and need a gas mask….
So what did I learn about code from University?Of course I learned the basics: how to solve a programming problem (don’t underestimate this!)<Read 1st bullet>unless I interview with Google (linked list, Back-Tracking Search, Bubble Sort,etc…)I did ACM competitions, Top Coder competitions, etc…I certainly got skills from doing that, but they were not skills about how to create maintainable, and/or scalable, applications.I was a CS TA for 3 years, and found teaching to be the best way for me to learn myself.(Not really anymore…)I really loved javadoc when I got out of school, I thought that was the best and only way to document code! How awesome is that, something creates docs right from your comments!HAHA ok enough with the java already! This is a RoRconf!
So what am I going to talk about next? C#... As a consultant, one of my favorite projects was building a financial forecasting system for a very large organization from scratch in C# .Net. It was a service oriented web application that was going to save all of their financial analysts tons and tons of time. We used the Windows Workflow Foundation framework for structuring the app. Anyone familiar with the WWF? Hehe I like to refer to that acronym because it’s reference to the world wrestling federation is appropriate – It’s a big show, and very few people get hurt.We had lots and lots and lots of code.But it wasn’t horrible code, it was very, very structured code. Everything with a similar purpose was grouped together, you knew where to look for a particular action, naming conventions and code patterns for methods were strictly enforced…. Even when they didn’t really make sense…..Our hound in this picture is just sneezing, he’s not terribly sick, but this somewhat nicely patterned behemoth of code never actually went into production… Also, our “test suite” was actually a team of testers with scripts they would run through any time the app changed. That is pretty typical big corporation waste from what I have seen.
So What did I learn about code here?Consistently adhering to patterns makes code written by different team members separately adhere together nicely.I certainly learned about single responsibility and abstractions, but there were patterns beaten into me that never really clicked:Always make your if statements positive, and you must always have an else when there is an if. What? Why?Well now I can say I understand that if you have an if, you are branching your code, and putting the else there makes that other branch explicit, therefore giving someone who comes after more information about what your code does.I can see the argument, but I would say now get rid of the branch and use polymorphism – objects are your friends!!!But again, this wasn’t Ruby, the framework wasn’t Rails, and this was enterprise level business practices – a much more restrictive environment than most of us in the RoR community work in.
So what was next?Ruby! Rails! Legacy Code?Best way to understand OO design principles is to work with code that doesn’t follow any. But it’s a rails app, it has MVC structure and separation of concerns at those layers, right?The model I’ve excerpted here has 2,533 linesThe dog in this picture says it all….So what do you do? This is production code, that the business and the customers depend on. There are bugs. (Did I really need to say that?) but really there are bugs that need fixing and feature requests that need implementation. You gotta deal with it, you gotta do it – That’s how I learned to smell code.
make sure there are tests! – Get the business requirements (AGAIN) from the end user – if it works in production that does not mean “don’t change it”, that means “Good the end users know the business process, and we can easily re-capture what this cluster is trying to do, and re-do it better”.
All of my first code looks like C#, because that’s the last language I knew, and there weren’t any good patterns to follow.I fought with Rails about how it structures data – I’m a db girl, who all of a sudden isn’t supposed to worry about the database anymore….When I found myself writing just as nasty (in terms of maintainability) code I looked for help.
Rails patterns are getting better and better:Coffee Script – makes our js less smelly – and there will be emerging new patterns here for maintaining all the gobs of client side code we are all writing
I talked about patterns to follow – here I’m talking about not following a pattern – when you follow an anti-pattern you will learn something – work with someone else who has a different pattern and learn together with them.The least smelly programmers are pair-programmers
If you have never seen the anit-patterns or code-smells talked about here, they may not click, but then re-read it. This is a reference manual, not a one-time-read.
Same idea here – this book is mentioned in Clean Code – read all the books in clean code’s bibliography – I have not gotten through all of them yet.
Lastly – pick up a hobby – you learn really cool things about what you do everyday when you do something else.From Rock climbing I’ve learned this about OO design patterns:It’s like learning to belay – you learn, you become a good belayer, It becomes muscle memory, but you don’t really get it, until one day it clicks – you’ve caught lots of falls, you’ve both lead climbed and caught a leader fall – you get how the system works and why the pattern / the rules you follow are there. That is when you can evolve and modify the system. You know when to follow the pattern and when to improvise. Do this with your code and help others do it – follow a couple good design patterns, make them muscle memory, and one day it will click, and then you can evolve your own patterns that will push the field forward. – If you’ve followed lots of good patterns, you will know how to make a good new one.
Not everyone has the same experiences you do, sometimes you need to write a bit of C# in ruby to figure out that ruby shouldn’t be written that way.I’ve found that these three things that are about learning and flexibility are more important to creating scentless code than anything else.For # 4 : It’s my pet peeve – I’m allowed one soap-box per talk, and this is it.every point in Chapter 17 (smells and heuristics) that is made about comments is 100% true. I’ve seen all of them, I’ve done a number of those things with comments myself. JUST STOP! Make your code document itself, no one who comes after you, who changes what your code does, will update your comments, but they will update your names and method signatures. And trust your source control – use Git for your comments – it’s a much better place for them. All of us think about the appropriate place for our code to go, think about the appropriate place for your comments.
