Upload
reneedv
View
1.248
Download
4
Embed Size (px)
DESCRIPTION
My talk from Conferencia Rails in Madrid Spain, in pdf format with my notes included.
Citation preview
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 ques>ons. I know! Audience par>cipa>on at a soBware conference, how awful of me! And just before lunch too! Don’t worry they are not ques>ons about food! Also, everyone has heard the term “code smell before right?”
1
Just for fun, how many of you are rock climbers?
2
Like Rails! Especially ones that follow or teach us maintainable paNerns and prac>ces of ways to structure code.
3
What is at the end of the Road? What’s the light at the end of the tunnel? I love descrip>ve analogies, especially ones that come with a picture of a dog! So which is it? I think I made this preNy obvious, but just in case.
4
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 ques>ons. 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 MicrosoB 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 varie>es, and each of the three different places where I have wriNen 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.
5
At university I did a lot of java and C programming Though 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 condi>onals: A situa>on I like to refer to as if-‐else-‐death. Working with teams was vile, Tests were unheard of And 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 >me 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….
6
So what did I learn about code from University? Of course I learned the basics: how to solve a programming problem (don’t underes>mate this!) <Read 1st bullet> unless I interview with Google (linked list, Back-‐Tracking Search, Bubble Sort, etc…) I did ACM compe>>ons, Top Coder compe>>ons, etc… I certainly got skills from doing that, but they were not skills about how to create maintainable, and/or scalable, applica>ons. 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 RoR conf!
7
So what am I going to talk about next? C#... As a consultant, one of my favorite projects was building a financial forecas>ng system for a very large organiza>on from scratch in C# .Net. It was a service oriented web applica>on that was going to save all of their financial analysts tons and tons of >me. We used the Windows Workflow Founda>on 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 federa>on 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 par>cular ac>on, naming conven>ons and code paNerns 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 paNerned behemoth of code never actually went into produc>on… Also, our “test suite” was actually a team of testers with scripts they would run through any >me the app changed. That is preNy typical big corpora>on waste from what I have seen.
8
So What did I learn about code here? Consistently adhering to paNerns makes code wriNen by different team members separately adhere together nicely. I certainly learned about single responsibility and abstrac>ons, but there were paNerns beaten into me that never really clicked: Always make your if statements posi>ve, 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 puong the else there makes that other branch explicit, therefore giving someone who comes aBer more informa>on 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 prac>ces – a much more restric>ve environment than most of us in the RoR community work in.
9
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 separa>on of concerns at those layers, right? The model I’ve excerpted here has 2,533 lines The dog in this picture says it all…. So what do you do? This is produc>on 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 implementa>on. You goNa deal with it, you goNa do it – That’s how I learned to smell code.
10
make sure there are tests! – Get the business requirements (AGAIN) from the end user – if it works in produc>on 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 beNer”.
11
All of my first code looks like C#, because that’s the last language I knew, and there weren’t any good paNerns 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 wri2ng just as nasty (in terms of maintainability) code I looked for help.
12
13
Rails paNerns are geong beNer and beNer: Coffee Script – makes our js less smelly – and there will be emerging new paNerns here for maintaining all the gobs of client side code we are all wri>ng
14
I talked about paNerns to follow – here I’m talking about not following a paNern – when you follow an an>-‐paNern you will learn something – work with someone else who has a different paNern and learn together with them. The least smelly programmers are pair-‐programmers
15
If you have never seen the anit-‐paNerns or code-‐smells talked about here, they may not click, but then re-‐read it. This is a reference manual, not a one-‐>me-‐read.
16
Same idea here – this book is men>oned in Clean Code – read all the books in clean code’s bibliography – I have not goNen through all of them yet.
17
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 paNerns: It’s like learning to belay – you learn, you become a good belayer, It becomes muscle memory, but you don’t really get it, un>l 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 paNern / the rules you follow are there. That is when you can evolve and modify the system. You know when to follow the paNern and when to improvise. Do this with your code and help others do it – follow a couple good design paNerns, make them muscle memory, and one day it will click, and then you can evolve your own paNerns that will push the field forward. – If you’ve followed lots of good paNerns, you will know how to make a good new one.
18
Not everyone has the same experiences you do, some>mes you need to write a bit of C# in ruby to figure out that ruby shouldn’t be wriNen that way. I’ve found that these three things that are about learning and flexibility are more important to crea>ng 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 heuris>cs) 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 aBer 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 beNer place for them. All of us think about the appropriate place for our code to go, think about the appropriate place for your comments.
19
20