Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so starting off this morning is Brian helm camp did I pronounce that right Brian all right so Brian a couple of high points Brian currently runs a company called code climate how many people are familiar with code climate okay if you're not check it out
great product I started using that after Ruby comp after she showed me the demo at rubyconf we started using it for our teams at AT&T for the projects that we have so in addition to code climate Brian is also heavily involved in as one of the lead organizers
for guru CO so I got clearance from him before using his Wi-Fi and guru CO for those of you aren't aware is a conference that takes place in New York City it's a similar single day single track conference well worth the trip and it's a great excuse
to go to New York so with that oh the other thing I wanted to mention is Brian is also was a ruby or is is a ruby hero as of 2009 if you're not familiar with the Ruby Heroes program google it and check it out it's a community effort where we actually
take the time to recognize about half a dozen members of the community each year for their extensive contributions to what we do and to help grow in the community and with that I'm gonna turn it over to Brian for a discussion that is not about Enterprise
Rails if you saw that on the schedule refresh your schedule this morning we're talking about refactoring active record this mic on can people hear me okay okay Thank You Koby I was a very nice introduction I'd like to begin with a little bit of group
therapy so think back to the last time you were working on a completely Greenfield application there was no legacy code there was no technical debt it was just you you had a test suite that was comprehensive but it ran really quickly you had a backlog of features
and you were just in your editor tearing through them and everyone think back to the last time they had that feeling give me an adjective for how you felt when you're working like that just toss one out there anybody got one fun productive anything else
what's that enabled yes great sane so so the Greenfield feeling is great right the problem is that as your requirements increase and you start adding developers to the project and the requirements start changing it's kind of like having cows entering
your green field and the problem with letting cows in your green field is after a while they have a tendency to turn a green field into a brown field and then you're sort of in that position where you feel like you're fighting your codebase have you
ever had that feeling where it feels like you have to change everything to get one thing done and it's your struggle your app is your adversary then you have to beat it into submission that's a brown field right so my name is Brian helm camp I'm
the founder of code climate it's a hosted automated service that does reviews of the Ruby code in your applications and today I'd like to talk about one particular aspect of this problem as it relates to rails applications we're gonna look at ways
to deal with complexity in our model layer and how we might be able to manage that complexity more effectively to prevent our green fields from turning brown so as a quick warning this talk is going to move really fast I'm gonna try to cover seven patterns
in one anti-pattern with an intro and an outro and time for questions in about 40 minutes so if you haven't had coffee yet god help you I'd like to begin with a quote rails makes it natural and easy to build large well-designed object-oriented systems
you know who said that I don't I don't think anybody has ever said that at least not to me but why is that I think in that context when someone might refer to Rails they're really referring to the active record pattern so we have to go back to
what the active record pattern is to understand this feeling active record was documented in Martin Fowler's book patterns of enterprise application architecture and if you go back to the source text he sort of clearly lays out some implications of using
the pattern the biggest advantage is simplicity and we feel this every day when we need to create a new model and layer on some quick and dirty crud sort of behavior plug it into some forms and and do your reads and writes from our database so it's very
simple and we can do that quickly on the other hand active records are by definition directly coupled to your database schema the problem with this is if you have a small database schema that isn't sort of expanding all the time and you restrict yourself
strictly to the active record pattern the tools that you end up with to manage complexity in your domain and in your model layer are very limited right if you only have five tables but you have all sorts of behaviors layered on top of them and you only have
five classes those five classes are going to become pretty problematic pretty quickly sometimes when people talk about object-oriented systems they use the term ravioli code and this can have sort of a positive or negative connotation depending on who's
talking about it or the context run they use the positive one here which is that you've got these little individual units of code which are loosely coupled they're all sort of sliding around in the same Bowl and they coordinate together to feed you
dinner rails is Cal's own code I believe David Chomsky coined this phrase and if you look at the picture you can just sort of get the feeling for why this fits your active records tend to be these big chunks right and you can you only have a few of them
if you eat more than two calzones you're just going feel really sick so today we're gonna look at a lot of ways to turn calzones into ravioli the problem with calzones is that they can tend to grow to even be God objects and if I were to look at your
applications today I would be fairly confident that there's at least two God objects in your application probably user or account whatever you want to call it and whatever the model is that's core to your application domain so if you're any commerce
application I would bet that the user class and the order class are probably the worst code that you've got to deal with and you probably dread going in there and making changes because who knows what's gonna fly out the other side so how do we solve
this in the past people have talked about the idea of skinny controllers and fat models they want their controllers to be limited in responsibilities to do one thing and one thing well and then offload that responsibility to someone else so the controllers
are very easy to understand and that you don't feel like you have to fight with them unfortunately I think skinny controller as a phrase has done perhaps as much damage as it's done good and there's a clear alternative right skinny controllers
and skinny models notice the pluralization on model 2 models and there's no reason we can't have the benefits of well encapsulated objects with limited responsibilities in our model layer just like we can have them in our controllable air onto the
patterns so there's gonna be a lot of code in the remaining slides if you can see if you can read the text on the bottom that says can you read this then you'll be able to read it on the projector if you can't read that you should pull up this
github repository which is gonna have all the code samples in it its github comm slash code climate slash refactoring - fat - models and if you don't have a laptop just maybe you can share over someone's shoulder but I want to begin with an anti-pattern
so whenever the topic of refactoring active records comes up one of the first things that people will talk about or sort of want to understand is this idea of extracting mix-ins and when I say mix-ins I mean Ruby modules so this would be like if you have a
[ ... ]
Nota: se han omitido las otras 3.920 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.